La programmation orientée objet est-elle vraiment aussi importante que les entreprises qui l'emploient? [fermé]

Je termine juste ma maîtrise (en informatique) et postule à des emplois. J'ai remarqué que de nombreuses entreprises demandent spécifiquement une compréhension de l'orientation des objets. Les questions d'entretien les plus populaires portent sur l'héritage, le polymorphisme, les accesseurs, etc.

Est-ce que OO est vraiment crucial? J'ai même eu une entrevue pour un poste de programmeur en C et la moitié de l'interview était de OO.

Dans le monde réel, en développant des applications réelles, l'orientation objet est-elle presque toujours utilisée? Des caractéristiques clés telles que le polymorphisme sont-elles utilisées BEAUCOUP?

Je pense que ma question vient d'une de mes faiblesses. Bien que je connaisse OO, il semble que je ne puisse pas 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 ne comprennent presque jamais car ils ne font que de petits projets d'une durée allant de deux semaines à deux mois tout au plus.

Cette courte période n'est pas suffisante pour définir clairement l'objectif de la programmation orientée objet, surtout si les participants au projet sont des débutants. Mais s’en tenir à une certaine modélisation est crucial pour les grands projets, je dirais> 50 000 lignes de code. La POO n'est pas la seule solution à ce problème, mais c'est la plus largement utilisée dans l'industrie.

C'est pourquoi les gens veulent que vous sachiez la programmation orientée objet.

J'ajouterais, par expérience, que presque tous les programmeurs débutants ont de graves défauts dans la modélisation et la programmation orientée objet. La plupart d'entre eux savent comment écrire des classes, en hériter et des choses basiques comme celles-là, mais ils ne pensent pas en "POO" et finissent par en abuser. C'est pourquoi tout recruteur sérieux examinera toujours quelles sont vos compétences dans le domaine de la programmation orientée objet.

Comme ces choses ne sont pas apprises à l’école, il existe tout simplement une énorme variation de connaissances entre différents candidats. Et soyons honnêtes: je ne pense pas qu'une personne connaissant mal OOP puisse travailler sur un grand projet, tout simplement parce que les développeurs principaux auraient plus de temps pour gérer ces personnes que de simplement écrire le code eux-mêmes.

Si vous ne pensez pas encore "POO", je vous suggérerais de lire quelques livres à ce sujet et de postuler dans une entreprise qui n'a pas vraiment de gros projets; pour vous habituer à ce que OOP continue à faire un travail utile pour votre employeur (et tant qu'il vous versera votre salaire, il vous sera utile également).

EDIT: ha, et j’ajouterais que j’avais déjà écrit le code OOP en C, même si ce n’est pas l’usage le plus courant du C, c’est possible avec de fortes connaissances. Vous devez juste construire vtables manuellement.

Et derrière la technique de la POO, quelque chose est caché: la conception de logiciels. La conception de logiciels est très utile, en C comme dans toutes les autres langues. De nombreux recruteurs vont tester vos compétences en matière de conception de logiciels, et la question de la programmation orientée objet y est bonne, mais la programmation orientée objet n'est pas la principale chose testée ici. C'est pourquoi vous avez ces questions même pour un travail en C.

Le principal problème de la programmation informatique est la complexité de la gestion. Les programmes modernes peuvent en effet être très complexes, et cela ne semble qu’augmenter.

Une grande partie du travail effectué dans le génie logiciel de programmes informatiques non triviaux se concentre sur l’apprivoisement de la complexité et le rend accessible au plus grand nombre possible sans consacrer au préalable une vie entière à l’apprentissage.

Exemples:

• Modularisation: Vous simplifiez conceptuellement les programmes en disposant des modules de code, chaque module ne connaissant qu'un peu les autres modules (au lieu de par exemple, un routage de dessin d'icône de souris étant autorisé à manipuler directement les tampons de la carte réseau).
• API: elles donnent un chemin d'utilisation simple aux programmes complexes derrière les API. Lorsque vous ouvrez un fichier, le fait que les partages réseau soient gérés différemment d’un disque USB n’importe pas. L'API est la même.
• Orientation d'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 masquant toute la complexité sous-jacente.

En d'autres termes, il est nécessaire de connaître de nombreuses astuces si vous souhaitez travailler sur des logiciels non triviaux, seuls ou (le plus souvent) 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 que, par conséquent, OO est très utilisé (y compris le polymorphisme, l'héritage et tout le reste).

Les entreprises ne se préoccupent pas spécifiquement de l'orientation des objets en tant que technologie - ce n'est pas une question d'idéologie, mais bien de ceux qui peuvent développer des solutions à leurs problèmes d'une manière qui correspond à leur stratégie informatique.

Mais je ne m'inquiéterais pas trop de sentir que c'est une faiblesse. Sans manquer de respect pour votre éducation, la plupart des gens dans le monde commercial ne voient pas les programmeurs quitter l'université (à quelque niveau que ce soit) comme un article fini. Il vous reste encore beaucoup à apprendre et c'est compris (probablement mieux par les entreprises que par les étudiants).

Comme dans la vie réelle, la programmation dans la vie réelle diffère de celle en théorie.

Oui, si vous maintenez le paradigme OO raffiné et toujours au fond de votre esprit, vous pourrez mieux écrire un code 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 localisées, plusieurs fournisseurs
• code hérité n'ayant aucune orientation que ce soit
• tant 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 "OO", il
• modules, limitations de plates-formes, 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, traitez cela comme un heads-up. Les entreprises qui embauchent accordent trop d’importance à l’OO lorsqu’elles embauchent. Il est facile de voir pourquoi. La seule façon de tester le candidat est de lui poser des questions sur la compréhension de OO. Et malheureusement, beaucoup de candidats se contentent d’aborder ces questions avant de se présenter pour une entrevue.

La vie réelle OO vient lentement. Cela aide si vous continuez à lire et continuez à l'améliorer au fil du temps.

J'ai eu à peu près le même sentiment lorsque j'ai terminé mon baccalauréat et un excellent livre qui m'a montré pourquoi et comment la POO est pertinente pour les applications du monde réel est Head First: Design Patterns . Je vous recommande sincèrement de jeter un coup d'oeil, il est écrit de manière vraiment amusante et explique de manière très pertinente pourquoi une approche POO est souhaitable pour travailler avec des systèmes à grande échelle et en constante évolution.

Même pour certains emplois en C, vous devrez peut-être connaître la conception orientée objet (et y être probablement plus performant que si votre compilateur le faisait pour vous), comme en témoigne une série récente 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 peut dire que 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é OO, vous trouvez les 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 ce code de jeu d'échecs OO:

-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 juste ceci:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

Par contre, si vous ne savez pas comment lire le code OO, inquiétez-vous. Parce que vous pouvez être sûr (ou presque) que votre code va jouer avec des objets. À moins que vous ne travailliez sur l'héritage historique de 12 000 vars et de 1200 modules en ligne que je gère 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 que, par conséquent, OO est très utilisé (y compris le polymorphisme, l'héritage et tout le reste).

C’est à peu près ce que j’allais dire, mais ce n’est pas seulement Java et .Net, le C ++ est partout, Objective-C est partout dans OSX, tous les enfants cools pratiquent Ruby ou Python, et toutes ces choses et beaucoup d’autres plus se concentrent sur l'orientation des objets. Beaucoup de nouveaux langages sont multiparadigm, donc quelque chose comme F # est avant tout un langage fonctionnel, mais supporte aussi l'orientation objet. C'est partout, et avoir au moins un peu de compréhension est très utile. Ne vous inquiétez pas trop, car vous venez tout juste de terminer des cours universitaires, vous êtes donc prêt à apprendre le développement de code dans le monde réel :)

Je fais 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, même si j'étais testé, je ne réussirais probablement pas à décrire ces concepts dans les moindres détails. À un moment donné, j'ai même créé un langage OO, bien que rudimentaire, pour me familiariser avec les concepts et trouver du plaisir dans OO sous un nouvel angle.

BTW, C ++ a fait un énorme et moche désordre de OO, alors que l’objectif C le fait bien.

En ce qui concerne les interviews, elles sont devenues un spectacle d'horreur - des deux côtés de la table. La plupart des personnes interrogées sont très effrayées par elles. La plupart des responsables du recrutement s’étonnent du nombre de personnes qui échouent même aux tests de programmation les plus élémentaires.

Cela dit, il existe actuellement dans l’industrie du logiciel d’énormes problèmes économiques qui ne connaissent rien et qui attendent pourtant le monde de futurs employés.

Apprendre la POO n'est pas aussi utile que l'apprentissage du développement de logiciels. Allez lire le code complet 2 .

Bien sûr, c’est un outil utile mais la POO elle-même est vraiment petite. En général, lorsque les entreprises et les recruteurs disent "POO", ils entendent par "développement de logiciels". Il est utilisé comme terme générique.

Les vrais recruteurs feront la différence entre savoir comment développer un logiciel et cocher la case "A 3 ans en" POO ".

La réponse est oui, comme plusieurs autres l'ont noté.

MAIS, si vous voulez travailler sur des piles 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 de gunslinger 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 bonne application de OO demande un travail et des réflexions réels. le simple fait d'en avoir quelques exemples ne signifie pas automatiquement qu'une application est bien faite. Et inversement, je suis sûr que le code de procédure est bien écrit. Mon expérience dans les magasins d’informatique d’entreprise des années 90 et 2000 a montré que beaucoup de mauvais codes ont été écrits et existent probablement encore. Mais plus près de la question du PO, j'ai remarqué que les développeurs les plus intelligents optent pour plus de systèmes OO.

OO est une base fondamentale sur laquelle d'autres techniques sont construites. 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 continuer à lire sans comprendre cela (pensant que cela deviendra clair plus tard), car vous devrez relire le reste une fois que vous aurez saisi la vision.

Une fois que vous aurez compris, vous ne voudrez plus vous en passer. Je ne suis pas un puriste en matière d'encapsulation, de motifs, de frameworks ou autres. Au travail, vous devrez vous adapter à divers points de vue et concepts. Je vais énumérer quelques expériences de travail de mes propres:

Dans une entreprise, mes collègues souhaitaient autant que possible un chargement paresseux (constructeurs vides, propriétés volumineuses qui devaient vérifier les valeurs nulles partout). Ils construisaient des objets Web côté serveur qui vivaient peu de temps.

Le travail suivant était totalement opposé. Objets vécus dans une application de bureau (basée sur Excel). Le constructeur doit être initialisé autant que possible (ou l'une des nombreuses surcharges du constructeur). Les constructeurs vides n'étaient pas autorisés car les objets vides n'avaient aucun droit d'existence (ce qui faisait de la persistance un défi). De plus, je devais m'adapter à leurs "normes de style de codage" (où ouvrir une parenthèse, ajouter des espaces après des commentaires, etc.), car mon code ne pourrait 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 en Grep. En fait, une macro HotScripts a été affectée à la touche F12 afin de créer un grep sur le texte sélectionné. Je vais épargner les autres frustrations ...

Une fois que vous aurez acquis les compétences requises pour devenir OO, vous serez presque allergique aux spaghettis! Cependant, dans tous les cas, OO-ou pas, soyez patient et adaptez-vous. Soyez réticent à "le jeter et recommencer". Votre patron préférera vous choisir quand il s’agit de jeter. Malheureusement, "faire de l'argent" est plus important qu'un code élégant.

Désolé pour la longue réponse mais j'ai essayé de couvrir la plus grande partie de votre question :-)

La POO n'est pas importante pour elle-même, mais pour ce qu'elle implique. Quelque chose qui traite de la capacité d’abstraction et d’isolement, de regrouper des éléments et d’exposer uniquement les éléments 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 en tant qu'agrégation de systèmes simples, sans s'occuper de tous les détails à un niveau élevé, et qui exigent que les composants soient remplaçables, même sans qu'ils soient exactement les mêmes. même.

On a essayé de garder ces "concepts d'ingénierie" 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", exigeant donc un moyen de faire en sorte que les développeurs travaillent sur des pièces indépendantes, interagir ensemble.

Cela dit, ces principes ne se retrouvent pas nécessairement uniquement dans la programmation orientée objet (si la théorie du calcul est valide, il existe une infinité de méthodes pour obtenir ces résultats).

La programmation orientée objet est simplement une tentative réussie de regrouper ces éléments, en donnant à ces termes généraux (tels que modules, encapsulation, substitution) des définitions plus précises et une conceptualisation élaborée de ces définitions (modèles) pouvant s'intégrer dans les langages de programmation.

Pensez d'abord à la programmation orientée objet, non pas comme une " fonctionnalité linguistique ", mais comme un " lexique commun " " permettant aux ingénieurs en logiciel de se familiariser avec la conception du logiciel.

Le fait qu’une langue donnée ait ou non des primitives qui appliquent directement ce lexique garantissant, par exemple, qu’une "capsule" n’est pas ouverte par inadvertance par celui qui n’est pas censé le faire est un aspect secondaire de la conception de la programmation orientée objet. 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 jusqu’à ce que la taille d’un projet reste inchangée est la capacité d’un développeur unique à comprendre et à suivre tout ce qu’il fait (en fait, dans une telle situation, cela peut même être perçu comme un "frais généraux"), ou encore à un petit groupe une courte période. Et c’est la raison principale pour laquelle les juniors qui ont étudié la POO en terme de "fonctionnalité de langage" l’interprètent souvent mal en produisant un code mal conçu.

La manière dont la POO s’intègre dans les langues dépend de la façon dont les concepteurs de langue interprètent le principe de la POO dans leur propre construction.

Ainsi, "encapsulation" en C ++ devient "membres privés" (et une "capsule" devient une classe), "substitution" devient une fonction virtuelle annulant ou paramétrisation / spécialisation de modèle, etc., tandis qu'en D une capsule est un "module" (et la substitution va etc.), rendant ainsi certains paradigmes ou modèles directement disponibles dans une langue donnée et non dans une autre, etc.

Ce que les recruteurs cherchent en posant la question de la programmation orientée objet, c’est simplement vérifier votre capacité à résumer et à concevoir des logiciels pour les futurs grands projets et développements. OOP, pour eux, ce n’est qu’un "dictionnaire", ils ont supposé que vous et eux le saviez afin que vous puissiez parler d’autres choses plus générales ou se concrétiser dans une implémentation spécifique.

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 tient probablement au succès commercial de java et de c #.

Si M. Gates avait créé sa société de la bonne manière, nous étudierions probablement SCHEME avant de postuler à un emploi.

Réponse courte est oui

La version longue pourquoi vous croyez que le problème est important ou qu’il vous semble difficile de le comprendre est uniquement due au fait que vous n’avez pas travaillé sur des projets ou des implémentations ayant une utilité quelconque. Il est parfaitement valable dans les salles de classe d’avoir des exemples sur l’automobile, puis de les étendre à des voitures, des camions ... mais lorsque vous vous lancez dans le développement de logiciels, c’est une solution visant à faciliter certaines tâches. Maintenant, si ce n'était pas étaient pourOO , tout le monde écrirait des codes similaires dans la base de codes ouréinventer les roues tous les jours. Imaginez quel gâchis ce serait si on devait plonger dans une telle base de code pour réparer quelque chose. Les exemples en classe sont pour une définition vague ou une représentation de comment / pourquoi cela est fait. Le vrai test est lancé lorsque vous commencez à créer votre application, sans aucun doute parce que tout ce qui est utilisé pourrait être terriblement utilisé, mais il pèse de loin sur la santé mentale en raison de son utilisation claire et concise. Il est donc préférable de commencer à travailler sur ces points faibles et de réduire les codes de cauchemar.

Ça dépend. Une des raisons pour lesquelles vous devez connaître OO est la lingua franca du monde de la programmation. Comme le souligne une autre réponse, presque toutes les langues principales sont OO, ce qui signifie que toute entreprise susceptible de vous engager utilise un langage OO. Avez-vous déjà essayé d’embaucher des programmeurs OCaml? C'est impossible; le bassin de talents est trop petit. Si vous avez démarré votre entreprise avec OCaml et que celle-ci connaît du succès, vous ne pourrez pas embaucher des programmeurs assez rapidement et vous ferez faillite. Par conséquent, presque toutes les entreprises comptant plus de 3 programmeurs utilisent un langage OO. Pour communiquer avec vos collègues et utiliser les bibliothèques de votre plate-forme, vous devez comprendre OO.

Selon la langue utilisée par la société, l'héritage et le polymorphisme sont extrêmement importants ou modérément pertinents. Vous ne pouvez rien faire en Java sans sortir 10 modèles de conception GoF et un framework d'injection de dépendance. Java est l’un des langages les plus largement utilisés. Par conséquent, les principes d’utilisation directe sont vraiment importants pour les nombreuses entreprises utilisant Java.

Si la société utilise un langage OO / fonctionnel hybride moderne comprenant des lambdas et des pointeurs de fonction, tels que Scala ou C #, l'héritage devient alors soudainement moins important, car vous disposez de fonctions d'ordre supérieur pour gérer beaucoup de choses très simples qui nécessiteraient autrement beaucoup la cérémonie. Cependant, vous devez toujours être capable de travailler avec des objets OO car la plupart des bibliothèques que vous utilisez seront écrites de manière OO.

Si l'héritage et le polymorphisme ne sont pas importants pour l'entreprise, vous risquez toujours de recevoir des questions sur OO pour les raisons suivantes:

• Vous êtes interrogé 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 plusieurs tâches, etc.
• Vous êtes interviewé par un ingénieur qui veut s'assurer que vous ne vivez pas sous un rocher. OO est la lingua franca, on vous posera donc quelques questions superficielles à ce sujet.
• Vous êtes interrogé par un ingénieur peu apte à l’interview. En général, les ingénieurs adorent les anecdotes et la complexité. Vous poserez donc de nombreuses questions sur le polymorphisme, l'héritage et les modèles de conception GoF uniquement parce que ces informations intéressent l'intéressé.

En un mot "oui".

Vous pensez peut-être connaître la théorie, mais vous devez écrire du code et le mettre en pratique. Il existe littéralement des milliers d'exemples et d'exercices disponibles en ligne.