La programmation OO est-elle vraiment aussi importante que l'embauche d'entreprises?
Je suis en train de terminer ma maîtrise (en informatique) et de postuler pour des emplois. J'ai remarqué que de nombreuses entreprises demandent spécifiquement une compréhension de l'orientation des objets. Les questions d'entrevue les plus fréquentes portent sur l'héritage, le polymorphisme, les accesseurs, etc.
Est OO vraiment si crucial? J'ai même eu une entrevue pour un travail de programmation en C et la moitié de l'entrevue était OO.
Dans le monde réel, en développant de vraies applications, l'orientation objet est-elle presque toujours utilisée? Les caractéristiques clés comme le polymorphisme sont-elles utilisées BEAUCOUP?
Je pense que ma question vient d'une de mes faiblesses. Bien que je connaisse OO, je ne semble pas être en mesure de l'intégrer beaucoup dans mes programmes.
La POO est un paradigme qui permet à votre programme de se développer sans devenir impossible à maintenir/à comprendre. C'est un point que les étudiants n'obtiennent presque jamais car ils ne font que de petits projets d'une durée de deux semaines à deux mois tout au plus.
Cette courte période ne suffit pas à rendre l'objectif de OOP clair, surtout si les gens sur le projet sont débutants. Mais s'en tenir à une certaine modélisation est crucial pour les grands projets, je dirais> 50 000 lignes de code . OOP n'est pas la seule solution à cela, mais c'est la plus largement utilisée dans l'industrie.
C'est pourquoi les gens veulent que vous connaissiez la POO.
J'ajouterais, par expérience, que presque tous les programmeurs juniors ont de sérieux défauts de modélisation et de POO. La plupart d'entre eux savent écrire des classes, en hériter et des trucs de base comme ça, mais ils ne pensent pas dans "OOP" et finissent par en abuser. C'est pourquoi tout recruteur sérieux recherchera toujours quelles sont vos compétences dans le domaine OOP.
Comme ces choses ne sont pas apprises à l'école, il y a simplement une énorme variation de connaissances entre les différents candidats. Et soyons honnêtes: je ne pense pas que quelqu'un avec une mauvaise connaissance en OOP puisse travailler sur n'importe quel grand projet, simplement parce qu'il faudrait plus de temps aux développeurs principaux pour gérer ces personnes que d'écrire simplement le se coder.
Si vous ne pensez pas encore "OOP", je vous suggère de lire quelques livres à ce sujet et de postuler dans une entreprise qui n'a pas vraiment de gros projets; pour vous habituer à OOP continuer à faire un travail utile pour votre employeur (et tant qu'il vous donnera votre salaire, cela vous sera utile aussi).
EDIT: ha, et j'ajouterais que j'ai déjà écrit OOP code en C, même si ce n'est pas l'utilisation la plus courante de C, cela est possible avec une connaissance approfondie. Il suffit de construire des vtables manuellement.
Et derrière la technique OOP, quelque chose est caché: la conception de logiciels. La conception de logiciels est vraiment utile, en C comme dans toutes les autres langues. De nombreux recruteurs testeront vos compétences en conception de logiciels et OOP question est bon pour cela, mais OOP n'est pas la principale chose qui est testée ici. C'est pourquoi vous avez ces questions même pour un travail C.).
Le problème majeur de la programmation informatique est la complexité de la gestion, et les programmes modernes peuvent être très complexes en effet, et cela semble ne faire qu'augmenter.
Une grande partie du travail effectué en génie logiciel des programmes informatiques non triviaux se concentre sur l'apprivoisement de la complexité et la rend accessible au plus grand nombre sans consacrer une vie entière à l'apprentissage.
Exemples:
- Modularisation: vous simplifiez conceptuellement les programmes en ayant des modules de code, où chaque module ne connaît que peu les autres modules (au lieu, par exemple, d'un icône de souris dessinant le routage étant autorisé à manipuler directement les tampons de carte réseau).
- API: ils donnent un chemin d'utilisation simple aux programmes complexes derrière les API. Lorsque vous ouvrez un fichier, peu importe que les partages réseau soient traités différemment d'un disque USB. L'API est la même.
- Orientation objet. Cela vous permet de réutiliser le code existant et de le faire fonctionner de manière transparente avec le nouveau code que vous ajoutez, tout en cachant toute la complexité sous-jacente.
En d'autres termes, connaître de nombreuses astuces est nécessaire si vous souhaitez travailler sur des logiciels non triviaux, seuls ou (très probablement) avec d'autres.
Oui, principalement parce que les deux plates-formes de développement les plus populaires utilisées dans le développement commercial (Java et .NET) sont orientées objet et cela signifie que oui, OO est beaucoup utilisé (y compris le polymorphisme, l'héritage et tout le reste) autre).
Les entreprises ne se soucient pas spécifiquement de l'orientation des objets en tant que technologie - ce n'est pas une question d'idéologie, elles se soucient des personnes qui peuvent développer des solutions à leurs problèmes d'une manière qui s'aligne sur leur stratégie informatique.
Mais je ne m'inquiéterais pas trop de sentir que c'est une faiblesse. Sans manquer de respect à votre éducation, la plupart des gens du monde commercial ne voient pas les programmeurs quitter l'université (à quelque niveau que ce soit) comme l'article fini. Il vous reste encore beaucoup à apprendre et c'est compris (probablement mieux par les entreprises que par les étudiants).
Comme dans la vraie vie, la programmation réelle diffère de celle de la théorie.
Oui, si vous gardez OO paradigme poli et toujours à l'esprit, vous pouvez faire mieux pour écrire du code qui est gérable, compréhensible et facilement extensible.
Malheureusement, le monde réel a ceci:
- contraintes de temps du projet
- membres de l'équipe orientés vers la procédure
- équipes réparties sur plusieurs sites, fournisseurs multiples
- code hérité n'ayant aucune orientation
- aussi longtemps que cela fonctionne, quelques soucis sur la façon dont le code est écrit
- même si le code ne fonctionne pas, la motivation est de le réparer, pas de le "OO"
- modules, limitations de plateforme, frameworks qui ne vous permettent tout simplement pas de faire du bon OO
Dans un vrai travail, vous devez travailler avec les problèmes ci-dessus. Cela semble démoralisant. Mais, considérez cela comme un avertissement. Les entreprises qui embauchent accordent trop d'importance à OO lors de l'embauche. Il est facile de comprendre pourquoi. La seule façon de tester le candidat est de se renseigner sur la compréhension d'OO. Et malheureusement, de nombreux candidats se contentent de réviser sur ces questions avant de se présenter pour une entrevue.
La vie réelle OO vient lentement. Cela aide si vous continuez à lire et à l'améliorer au fil du temps.
J'ai eu le même sentiment à la fin de mon baccalauréat, et un excellent livre qui m'a montré pourquoi et comment OOP est pertinent pour les applications du monde réel est Head First: Design Patterns. Je vous recommande sincèrement de jeter un coup d'œil, il est écrit de manière très amusante et explique pourquoi une approche POO est souhaitable lorsque vous travaillez avec des systèmes à plus grande échelle et en constante évolution.
Même pour certains travaux en C, vous devrez peut-être connaître la conception orientée objet (et probablement être meilleur que si votre compilateur le faisait pour vous), comme en témoigne une récente série d'articles sur la conception orientée objet dans le noyau Linux. ( partie 1 , partie 2 )
GTK + utilise également de nombreux modèles de conception orientés objet.
Je dois exprimer un certain désaccord avec cette notion selon laquelle OO est tout - on pourrait dire OO vous permet de construire des villes, mais les programmes procéduraux sont les briques).
Pour donner ma réponse sous forme d'analogie, un général a besoin d'objets, le soldat a besoin de procédure. Une fois que vous avez suffisamment exploré dans OO vous trouvez des procédures, et si c'est votre expertise et que vous êtes assez bon, ne vous inquiétez pas pour OO, car il est assez facile pour quelqu'un d'écrire ceci = OO code du jeu d'échecs:
-findBestMove
-makeBestMove
-waitForPlayerInput
mais alors quelqu'un doit écrire le code derrière -findBestMove et vous pouvez être sûr que ce n'est pas seulement cela:
foreach $move (@moves){
$bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove
D'un autre côté, si vous ne savez pas lire le code OO, inquiétez-vous. Parce que vous pouvez être sûr (presque) que votre code va jouer avec des objets d'une certaine sorte. À moins que vous travaillez sur le géant fortran hérité de 12000 vars globaux et 1200 "modules" de ligne que je maintiens actuellement.
Jon Hopkins a écrit:
Oui, principalement parce que les deux plates-formes de développement les plus populaires utilisées dans le développement commercial (Java et .NET) sont orientées objet et cela signifie que oui, OO est beaucoup utilisé (y compris le polymorphisme, l'héritage et tout le reste) autre).
Ce qui est à peu près ce que j'allais dire, mais ce n'est pas seulement Java et .Net, C++ est partout, Objective-C est partout dans OSX, tous les enfants cool font Ruby ou Python, et toutes ces choses et bien d'autres encore se concentrent sur l'orientation des objets. Beaucoup de nouveaux langages sont multiparadigm, donc quelque chose comme F # est principalement un langage fonctionnel, mais prend également en charge l'orientation des objets. Il est partout et avoir au moins une certaine compréhension est très utile.Ne vous inquiétez pas trop, cependant, après avoir terminé des cours universitaires, vous êtes prêt à commencer à apprendre à développer du code dans le monde réel :)
J'ai fait de la programmation depuis longtemps, et je trouve que les concepts de OO sont utiles même lors de la programmation en C - même si testés je ne parviendrais probablement pas à décrire ces concepts dans chaque minuscule À un moment donné, j'ai même créé un langage OO, quoique rudimentaire, pour me familiariser avec les concepts et trouver du plaisir dans OO de un nouvel angle.
BTW, C++ a fait un gâchis énorme et laid d'OO, tandis que Objective C le fait correctement.
Quant aux interviews, elles sont devenues un spectacle d'horreur - des deux côtés de la table. La plupart des personnes interrogées en sont très flippées. La plupart des responsables du recrutement sont étonnés du nombre de personnes qui échouent même aux tests de programmation très basiques.
Cela dit, il y a actuellement d'énormes sacs de douche travaillant dans l'industrie du logiciel qui ne connaissent RIEN et attendent pourtant le monde des employés potentiels.
Apprentissage OOP n'est pas aussi utile que le développement de logiciels d'apprentissage. Allez lire Code Complete 2 .
Bien sûr, c'est un outil utile mais OOP lui-même est vraiment petit. En général, lorsque les entreprises et les recruteurs disent "OOP", ils signifie "développement de logiciels". Il est utilisé comme un terme générique.
De vrais recruteurs feront la différence entre savoir comment développer un logiciel et faire cocher la case "A 3 ans dans 'OOP'".
La POO n'est pas importante à cause d'elle-même, mais à cause de ce qu'elle emporte. Quelque chose qui traite de la capacité d'abstraire et d'isoler, de regrouper des choses ensemble et d'exposer uniquement les parties nécessaires pour interagir ensemble.
Il s'agit d'une technique d'ingénierie courante appelée "modularisation", qui permet de créer des systèmes complexes comme agrégation de systèmes plus simples, sans prendre soin de tous les détails à un niveau élevé, et qui nécessitent que les composants soient remplaçables, même sans qu'ils soient exactement les même.
Ces "concepts d'ingénierie" ont été essayés pour être maintenus dans le développement logiciel à partir du moment où le produit logiciel lui-même était devenu plus grand que la "capacité de développeur unique", nécessitant ainsi un moyen de faire travailler les développeurs sur des pièces indépendantes, et de laisser ces pièces à interagir ensemble.
Cela dit, ces principes ne se trouvent pas nécessairement uniquement dans OOP (si la théorie du calcul est valide, il existe une infinité de méthodes possibles pour arriver à ces résultats).
La POO est simplement une tentative réussie de rassembler ces choses, donnant à ces termes généraux (comme les modules, l'encapsulation, la substitution) des définitions plus précises et une conceptualisation élaborée de ces définitions (modèles) qui peuvent s'intégrer dans les langages de programmation .
Pensez à OOP d'abord non pas comme un "fonction linguistique" mais comme un "Lexicon commun" qui oblige les ingénieurs logiciels à aborder la conception du logiciel.
Le fait qu'une langue donnée ait ou non des primitives qui imposent directement ce lexique garantissant - par exemple - qu'une "capsule" n'est pas ouverte par inadvertance par qui n'est pas censé le faire est un aspect secondaire de la conception de [OOP . C'est pourquoi même les grands projets C sont souvent "gérés en tant que" POO, même si le langage lui-même n'offre aucun support direct à cela.
L'avantage de tout ce qui n'est pas reconnaissable tant qu'une taille de projet ne reste pas dans la capacité d'un seul développeur à comprendre et à suivre tout ce qu'il fait (en fait, dans ces situations, cela peut même être considéré comme "aérien") ou dans un petit groupe développant quelque chose dans une courte période. Et c'est la raison principale pour laquelle les juniors qui ont étudié OOP en termes de "fonctionnalité de langage" l'interprètent souvent de manière erronée en produisant un code mal conçu.
La façon dont OOP s'intègre dans les langues dépend de la façon dont les concepteurs de langage interprètent le principe OOP dans leur propre construction.
Ainsi, "l'encapsulation" en C++ devient des "membres privés" (et une "capsule" devient une classe), la "substitution" devient un remplacement de fonctions virtuelles ou un paramétrage/spécialisation de modèle, etc., tandis qu'en D une capsule est un "module" (et la substitution va cours, etc.), rendant ainsi certains paradigmes ou schémas directement disponibles dans une langue donnée et non dans une autre, etc.
Ce que les recruteurs recherchent en posant OOP question est simplement de vérifier votre capacité à résumer et à concevoir la conception de logiciels pour de futurs grands projets et développements. OOP, pour eux, c'est juste un "dictionnaire" qu'ils supposaient que vous et eux saviez pour que vous puissiez parler d'autres choses plus générales ou concrétiser dans une implémentation spécifique.
La réponse est oui, comme plusieurs autres l'ont noté.
MAIS, si vous voulez travailler sur des tas de code spaghetti procédural non-OO, vous pouvez le trouver aussi. Je pense que vous préférerez le travail OO.
EDIT: Pardonnez mon cas de cynisme et de sens de l'humour. Comme Raynos l'a dit, ce n'est pas parce que quelque chose est OO que c'est bon. Une application appropriée de OO requiert un travail et une réflexion réels; le simple fait d'en avoir des instances ne signifie pas automatiquement qu'une application est bien conçue. Et inversement, je suis sûr qu'il existe un code de procédure bien écrit. D'après mon expérience dans les magasins informatiques d'entreprise dans les années 90 et 2000, beaucoup de mauvais code ont été écrits et existent probablement toujours. Mais plus près de la question de l'OP, j'ai remarqué que les développeurs les plus intelligents, lorsqu'ils en ont l'occasion, se tournent vers davantage de systèmes [OO.
L'OO est une base fondamentale sur laquelle reposent d'autres techniques. Un point clé est d'abord de bien comprendre la différence entre un type (classe) et une instance de ce type. N'essayez pas de lire sans bien comprendre cela (en pensant que cela deviendra clair plus tard), car vous devrez lire le reste une fois que vous aurez saisi la vision.
Une fois que vous aurez compris, vous ne voudrez plus jamais vous en passer. Je ne suis pas un puriste en ce qui concerne l'encapsulation, les modèles, les cadres ou quoi que ce soit. Au travail, vous devrez vous adapter à divers points de vue et concepts. Je vais énumérer certaines de mes expériences professionnelles précédentes:
Dans une entreprise, mes pairs voulaient autant que possible le chargement paresseux (constructeurs vides, propriétés volumineuses qui devaient vérifier les valeurs nulles partout). Ils construisaient des objets côté serveur basés sur le Web qui ont vécu une courte vie.
Le travail suivant était totalement opposé. Les objets vivaient dans une application de bureau (basée sur Excel). Autant d'initialisation que possible devrait être dans le constructeur (ou l'une des nombreuses surcharges de constructeur). Les constructeurs vides n'étaient pas autorisés car les objets vides n'avaient pas de droit d'existence (ce qui rendait la persistance assez difficile). De plus, j'ai dû m'adapter à leurs "normes de style de codage" (où ouvrir les parenthèses, ajouter des espaces après les commentaires etc ...), car mon code ne pouvait pas être archivé s'il ne passait pas par style-cop.
Actuellement, je travaille dans une entreprise où aucun des développeurs n'a jamais essayé de comprendre OO. Il est difficile d'exprimer à quel point cela a été extrêmement frustrant. J'ai dû améliorer mes compétences Grep, en fait j'ai une macro HotScripts affectée à ma touche F12 afin de faire un grep sur le texte sélectionné. Je vais épargner les autres frustrations ...
Une fois que vous aurez acquis les compétences OO, vous serez presque allergique aux spaghettis! Cependant, dans tous les cas, OO-ou pas, soyez patient et adaptez-vous. Votre patron préfère vous choisir quand il s'agit de jeter. Malheureusement, "faire de l'argent" est plus important que du code élégant.
Désolé pour la longue réponse mais j'ai essayé de couvrir la plupart de la portée de votre question :-)
La réponse courte est oui
La version plus longue pour laquelle vous vous sentez ou dans un dilemme quant à pourquoi son importance est uniquement due au fait que vous n'avez travaillé sur aucun projet ou implémentation qui sert à quelque chose. C'est parfaitement valable dans les salles de classe pour avoir des exemples sur l'automobile puis étendu à la voiture, aux camions ... mais lorsque vous vous lancez dans le développement de logiciels, c'est une solution ciblée pour faciliter certaines tâches. Maintenant, si ce n'était pas pour OO nous aurions tout le monde écrit des codes similaires à travers la base de code ou réinventer les roues au quotidien. Imaginez quel gâchis ce serait si on plongeait dans une telle base de code pour réparer quelque chose. Les exemples en classe sont pour une définition ou une représentation vague de comment/pourquoi cela est fait. Le vrai test est sorti lorsque vous commencez à créer votre application, sans aucun doute car tout ce qui pourrait être terriblement utilisé, mais il pèse loin sur la raison en raison de son utilisation claire et concise. Il vaut donc mieux commencer à travailler sur ces points faibles, moins vous produisez des codes de cauchemar.
Ça dépend. Une raison pour laquelle vous devez connaître OO parce que c'est la lingua franca du monde de la programmation. Comme le souligne une autre réponse, presque toutes les langues principales sont en quelque sorte OO, ce qui signifie que pratiquement toute entreprise qui pourrait vous embaucher utilise une langue OO. Avez-vous déjà essayé d'embaucher des programmeurs OCaml? C'est impossible; le vivier de talents est trop petit. Si vous avez démarré votre entreprise en utilisant OCaml et que votre entreprise réussit, vous ne pourrez pas embaucher des programmeurs assez rapidement et vous cesserez vos activités. Par conséquent, presque toutes les entreprises comptant plus de 3 programmeurs utilisent un langage OO, et afin de communiquer avec vos collègues et d'utiliser les bibliothèques de votre plate-forme, vous aurez besoin de comprendre OO.
Selon le langage particulier utilisé par l'entreprise, l'héritage et le polymorphisme sont soit extrêmement importants, soit tout simplement modérément pertinents. Vous ne pouvez rien faire dans Java sans casser 10 modèles de conception GoF et un cadre d'injection de dépendances. Java est l'un des langages les plus utilisés, donc les principes OO sont vraiment importants pour les nombreuses entreprises utilisant Java.
Si l'entreprise utilise un langage OO/fonctionnel hybride moderne doté de lambdas et de pointeurs de fonction, comme Scala ou C #, l'héritage devient soudain moins important car vous avez des fonctions d'ordre supérieur pour gérer beaucoup de choses vraiment simples qui sinon, il faut beaucoup de cérémonie. Cependant, vous devez toujours être en mesure de travailler avec des éléments OO car la plupart des bibliothèques que vous utilisez seront écrites de manière OO.
Si l'héritage et le polymorphisme ne le sont pas sont importants pour l'entreprise, vous risquez toujours de recevoir OO des questions car:
- Vous êtes interviewé par une personne des ressources humaines qui ne connaît rien à la programmation et pose des questions sur une liste de contrôle. Avez-vous 3 ans de X, faites-vous du multitâche, etc.
- Vous êtes interviewé par un ingénieur qui veut s'assurer que vous n'avez pas vécu sous un rocher. OO est la lingua franca, donc on vous posera quelques questions superficielles à ce sujet.
- Vous êtes interviewé par un ingénieur qui n'est pas très habile à interviewer. En général, les ingénieurs adorent les anecdotes et la complexité, vous aurez donc beaucoup de questions sur le polymorphisme, l'héritage et les modèles de conception GoF uniquement parce que ces choses sont intéressantes pour la personne qui vous interroge.
Un langage orienté objet vous aide à conserver une conception orientée objet dans votre code, ce qui est bien. Mais il est également vrai qu'une telle conception peut être obtenue avec n'importe quel autre langage de paradigme: la raison de la popularité (en particulier parmi les entreprises) des langages OO réside probablement dans le succès commercial de Java et c # .
Si M. Gates avait démarré son entreprise dans le bon sens, nous étudierions probablement SCHEME avant de postuler un emploi.