La méthode OOP est-elle utilisée de manière abusive dans les universités ?

Question

J'ai créé mon collège il y a deux ans, et depuis, je n'arrête pas d'entendre dire "concevez d'abord vos classes". Je me demande parfois si ma solution ne devrait pas être un tas d'objets en premier lieu ! Certains disent que vous n'en voyez pas les avantages parce que votre base de code est très petite - les projets universitaires. L'excuse de la taille du projet ne me convient pas. Si la solution convient au projet, je pense qu'elle devrait également convenir à la macro-version de ce projet.

Je ne dis pas que la POO est mauvaise, mais j'ai l'impression qu'elle est utilisée de manière abusive dans les salles de classe où l'on dit jour et nuit à des étudiants comme moi que la POO est la bonne voie .

Pour moi, la bonne réponse ne devrait pas venir d'un professeur, je préfère l'entendre de la bouche de vrais ingénieurs sur le terrain.

L'approche OOP est-elle toujours la bonne ?

Quand l'approche OOP est-elle la meilleure ?

Quand la méthode OOP est-elle une mauvaise approche ?

Il s'agit d'une question très générale. Je ne demande pas de réponses définitives, mais simplement une expérience réelle de conception sur le terrain.

Je ne me préoccupe pas des performances. Je m'interroge sur la conception. Je sais qu'il s'agit d'ingénierie dans la vie réelle.

\==================================================================================

Merci pour toutes les contributions. J'ai choisi la réponse de Nosredna, car elle a répondu à mes questions de manière générale et m'a convaincu que je me trompais sur les points suivants : Si la solution convient au projet, je pense qu'elle devrait également convenir à la macro-version de ce projet.

Answer 1

Les professeurs ont l'inconvénient de ne pas pouvoir vous faire travailler sur d'énormes et méchants programmes qui durent des années et sur lesquels travaillent de nombreux programmeurs différents. Ils doivent utiliser des exemples de jouets peu convaincants et essayer de vous faire voir la situation dans son ensemble.

Il s'agit essentiellement de vous faire croire que lorsqu'un train miniature de taille HO vous percute, il vous arrache la jambe. Seuls les professeurs les plus convaincants y parviennent.

---

"Si la solution convient au projet, je pense qu'elle devrait également convenir à la macro-version de ce projet.

C'est là que je ne suis pas d'accord. Un petit projet s'adapte à votre cerveau. La grande version ne l'est peut-être pas. Pour moi, l'avantage de l'OO est de cacher suffisamment de détails pour que la vue d'ensemble puisse encore tenir dans ma tête. Si vous n'avez pas d'OO, vous pouvez toujours vous débrouiller, mais cela signifie qu'il faut trouver d'autres moyens de cacher la complexité.

Ne perdez pas de vue le véritable objectif : produire un code fiable. L'OO fonctionne bien dans les grands programmes parce qu'elle vous aide à gérer la complexité. Elle permet également de faciliter la réutilisation.

Mais l'OO n'est pas l'objectif. L'objectif est d'avoir un bon code. Si une approche procédurale fonctionne et ne devient jamais complexe, vous avez gagné !

Answer 2

L'OOP est un concept informatique du monde réel que l'université aurait tort de ne pas intégrer dans le programme d'études. Lorsque vous postulerez à un emploi, on attendra de vous que vous le maîtrisiez.

Cela dit, comme jalf, la POO a d'abord été conçue comme un moyen de gérer la complexité. Les projets universitaires rédigés par un ou deux étudiants pendant leur temps de travail ne constituent pas un cadre réaliste pour des projets de grande envergure comme celui-ci, de sorte que les exemples ont l'air (et sont) des exemples-jouets.

Il est également important de comprendre que tout le monde ne voit pas la POO de la même manière. Certains y voient une question d'encapsulation et créent d'énormes classes très complexes, mais dont l'état est caché à tout appelant extérieur. D'autres veulent s'assurer qu'un objet donné n'est responsable que d'une seule chose et créent un grand nombre de petites classes. Certains recherchent un modèle d'objet qui reflète étroitement les abstractions du monde réel auxquelles le programme essaie de se rattacher, d'autres considèrent que le modèle d'objet concerne la manière d'organiser l'architecture technique du problème, plutôt que le modèle d'entreprise du monde réel. Il n'y a pas de une seule et unique voie avec la POO, mais à la base, elle a été introduite comme un moyen de gérer la complexité et de faire en sorte que les programmes plus importants soient plus faciles à maintenir au fil du temps.

Answer 3

La POO est la bonne approche lorsque vos données peuvent être structurées en objets.

Par exemple, pour un dispositif intégré qui traite un flux d'octets provenant d'un capteur, il n'y a pas grand-chose qui puisse être clairement objectivé.

De même, dans les cas où un contrôle ABSOLU des performances est essentiel (lorsque chaque cycle compte), une approche OOP peut introduire des coûts qu'il n'est pas toujours facile de calculer.

Dans le monde réel, la plupart du temps, votre problème peut être TRÈS bien décrit en termes d'objets, bien que les loi sur les abstractions qui fuient ne doivent pas être oubliés !

L'industrie se résout généralement, en fin de compte, à utiliser le bon outil pour le travail, et vous pouvez voir OOP dans de nombreux endroits. Des exceptions sont souvent faites pour la haute performance et le bas niveau. Bien entendu, il n'y a pas de règle absolue.

Il est possible d'enfoncer une vis à l'aide d'un marteau si l'on s'y attarde suffisamment longtemps...

Answer 4

Mes 5 centimes :

La POO n'est qu'un exemple d'un modèle plus large : traiter la complexité en décomposant un problème important en problèmes plus petits. Nos faibles esprits sont limités à un petit nombre d'idées qu'ils peuvent traiter à tout moment. Même une application commerciale de taille modérée comporte plus de pièces mobiles que la plupart des gens ne peuvent en garder une image mentale complète à la fois. Certains des paradigmes de conception les plus réussis dans le domaine du génie logiciel s'appuient sur la notion de gestion de la complexité. Qu'il s'agisse de diviser votre architecture en couches, votre programme en modules, de procéder à une décomposition fonctionnelle des actions, d'utiliser des composants préconstruits, de tirer parti de services web indépendants ou d'identifier des objets et des classes dans vos espaces de problème et de solution. Ce sont tous des outils qui permettent de dompter la bête qu'est la complexité.

La POO s'est avérée particulièrement efficace dans plusieurs catégories de problèmes. Elle fonctionne bien lorsqu'il est possible d'envisager le problème en termes de "choses" et d'interactions entre elles. Elle fonctionne très bien lorsque vous traitez des données, des interfaces utilisateur ou que vous construisez des bibliothèques à usage général. La prévalence de ces classes d'applications a contribué à rendre la POO omniprésente. D'autres catégories de problèmes nécessitent des outils différents ou supplémentaires. Les systèmes d'exploitation distinguent le noyau et l'espace utilisateur, et isolent les processus en partie pour éviter l'extension de la complexité. La programmation fonctionnelle maintient les données immuables pour éviter le maillage de dépendances qui se produit avec le multithreading. Ni l'un ni l'autre n'est une conception classique de la POO et pourtant ils sont cruciaux et réussissent dans leurs propres domaines.

Au cours de votre carrière, vous serez probablement confronté à des problèmes et à des systèmes plus importants que ceux auxquels vous pourriez vous attaquer seul. Votre professeur n'essaie pas seulement de vous doter des outils actuels du métier. Ils essaient de vous faire comprendre qu'il existe des modèles et des outils que vous pouvez utiliser lorsque vous tentez de modéliser les problèmes du monde réel. Il est dans votre intérêt d'accumuler une collection d'outils pour votre boîte à outils et de choisir le(s) bon(s) outil(s) pour le travail. La POO est un outil puissant, mais ce n'est pas le seul.

Answer 5

1. Non... le mode opératoire n'est pas toujours la meilleure approche.

2. (Vrai) La conception OOP est la meilleure approche lorsque votre problème peut être modélisé comme un ensemble d'objets qui peuvent atteindre vos objectifs en communiquant/utilisant les uns les autres.

3. Bonne question... mais je suppose que les applications scientifiques et analytiques sont probablement le meilleur exemple. La majorité de leurs problèmes peuvent être abordés par la programmation fonctionnelle plutôt que par la programmation orientée objet.

...Ceci étant dit, que les flammes commencent. Je suis sûr qu'il y a des lacunes et j'aimerais bien savoir pourquoi.