Quel est l'intérêt de la POO?

Pour autant que je sache, malgré les millions ou milliards dépensés pour l'éducation, les langages et les outils de la POO, la POO n'a pas amélioré la productivité des développeurs ou la fiabilité des logiciels, ni réduit les coûts de développement. Peu de gens utilisent la POO dans un sens rigoureux (peu de gens adhèrent ou comprennent des principes tels que LSP); il semble y avoir peu d'uniformité ou de cohérence dans les approches adoptées par les gens pour modéliser les domaines problématiques. Trop souvent, la classe est utilisée simplement pour son sucre syntaxique; il place les fonctions d'un type d'enregistrement dans leur propre petit espace de noms.

J'ai écrit une grande quantité de code pour une grande variété d'applications. Bien qu'il y ait eu des endroits où un véritable sous-typage substituable a joué un rôle précieux dans l'application, ceux-ci ont été assez exceptionnels. En général, bien que l'on parle de «réutilisation» du bout des lèvres, la réalité est qu'à moins qu'un morceau de code fasse exactement ce que vous voulez qu'il fasse, il y a très peu de «réutilisation» rentable. Il est extrêmement difficile de concevoir des classes pour être extensibles de la bonne manière , et donc le coût de l'extension est normalement si élevé que la «réutilisation» n'en vaut tout simplement pas la peine.

À bien des égards, cela ne me surprend pas. Le monde réel n'est pas "OO", et l'idée implicite dans OO - que nous pouvons modéliser les choses avec une taxonomie de classe - me semble très fondamentalement imparfaite (je peux m'asseoir sur une table, une souche d'arbre, un capot de voiture , les genoux de quelqu'un - mais pas l'un de ceux-ci est une chaise). Même si nous passons à des domaines plus abstraits, la modélisation OO est souvent difficile, contre-intuitive et finalement inutile (considérez les exemples classiques de cercles / ellipses ou de carrés / rectangles).

Alors qu'est-ce que je manque ici? Où est la valeur de la POO et pourquoi tout le temps et l'argent n'ont-ils pas réussi à améliorer les logiciels?

Il n'y a aucune preuve empirique qui suggère que l'orientation objet est une façon plus naturelle pour les gens de penser au monde. Il y a des travaux dans le domaine de la psychologie de la programmation qui montrent que l'OO n'est pas en quelque sorte plus approprié que d'autres approches.

Les représentations orientées objet ne semblent pas être universellement plus ou moins utilisables.

Il ne suffit pas d'adopter simplement des méthodes OO et d'exiger des développeurs qu'ils utilisent de telles méthodes, car cela pourrait avoir un impact négatif sur la productivité des développeurs, ainsi que sur la qualité des systèmes développés.

Ce qui est tiré de "Sur l'utilisabilité des représentations OO" de Communications of the ACM oct. 2000. Les articles comparent principalement OO à l'approche orientée processus. Il y a beaucoup d'études sur la façon dont les gens qui travaillent avec la méthode OO «pensent» (Int. J. of Human-Computer Studies 2001, numéro 54, ou Human-Computer Interaction 1995, vol. 10 a tout un thème sur les études OO), et d'après ce que j'ai lu, rien n'indique une sorte de naturel à l'approche OO qui la rend mieux adaptée qu'une approche procédurale plus traditionnelle.

Le monde réel n'est pas "OO", et l'idée implicite dans OO - que nous pouvons modéliser les choses avec une taxonomie de classe - me semble fondamentalement imparfaite

Bien que cela soit vrai et ait été observé par d'autres personnes (prenez Stepanov, inventeur de la STL), le reste est absurde. La POO peut être imparfaite et ce n'est certainement pas une solution miracle, mais elle rend les applications à grande échelle beaucoup plus simples car c'est un excellent moyen de réduire les dépendances. Bien sûr, cela n'est vrai que pour la «bonne» conception de la POO. Un design bâclé ne donnera aucun avantage. Mais une bonne conception découplée peut être très bien modélisée en utilisant la POO et pas bien en utilisant d'autres techniques.

Il existe des modèles bien meilleurs et plus universels (on pense au modèle de type Haskell ), mais ils sont aussi souvent plus compliqués et / ou difficiles à mettre en œuvre efficacement. La POO est un bon compromis entre les extrêmes.

La POO ne consiste pas à créer des classes réutilisables, mais à créer des classes utilisables.

Trop souvent, la classe est utilisée simplement pour son sucre syntaxique; il place les fonctions d'un type d'enregistrement dans leur propre petit espace de noms.

Oui, je trouve cela trop répandu aussi. Il ne s'agit pas de programmation orientée objet. C'est la programmation basée sur les objets et la programmation centrée sur les données. Au cours de mes 10 années de travail avec les langages OO, je vois des gens faire principalement de la programmation basée sur les objets. OBP tombe en panne très rapidement IMHO puisque vous obtenez essentiellement le pire des deux mots: 1) Programmation procédurale sans adhérer à la méthodologie de programmation structurée éprouvée et 2) POO sans adhérer à la méthodologie éprouvée de la POO.

La POO bien faite est une belle chose. Cela rend les problèmes très difficiles à résoudre, et pour les non-initiés (n'essayant pas de paraître pompeux là-bas), cela peut presque sembler magique. Cela étant dit, la POO n'est qu'un outil dans la boîte à outils des méthodologies de programmation. Ce n’est pas la méthodologie à tout faire. Cela convient parfaitement aux grandes applications d'entreprise.

La plupart des développeurs qui travaillent dans des langages POO utilisent des exemples de POO exécutés directement dans les frameworks et les types qu'ils utilisent quotidiennement, mais ils n'en sont tout simplement pas conscients. Voici quelques exemples très simples: ADO.NET, Hibernate / NHibernate, Logging Frameworks, différents types de collection de langage, la pile ASP.NET, la pile JSP etc ... Ce sont toutes des choses qui reposent fortement sur la POO dans leurs bases de code.

La réutilisation ne devrait pas être un objectif de la POO - ou de tout autre paradigme d'ailleurs.

La réutilisation est un effet secondaire d'une bonne conception et d'un niveau d'abstraction approprié. Le code réalise la réutilisation en faisant quelque chose d'utile, mais pas au point de le rendre inflexible. Peu importe que le code soit OO ou non - nous réutilisons ce qui fonctionne et ce n'est pas trivial de le faire nous-mêmes. C'est du pragmatisme.

La pensée de l'OO comme une nouvelle façon de se réutiliser par héritage est fondamentalement imparfaite. Comme vous le constatez, les violations LSP abondent. Au lieu de cela, OO est correctement considéré comme une méthode de gestion de la complexité d'un domaine de problème. L'objectif est la maintenabilité d'un système dans le temps. Le principal outil pour y parvenir est la séparation de l'interface publique d'une implémentation privée. Cela nous permet d'avoir des règles comme "Cela ne devrait être modifié qu'en utilisant ..." appliquées par le compilateur, plutôt que la révision du code.

En utilisant cela, je suis sûr que vous en conviendrez, nous permet de créer et de maintenir des systèmes extrêmement complexes. Il y a beaucoup de valeur à cela, et ce n'est pas facile à faire dans d'autres paradigmes.

À la limite du religieux, mais je dirais que vous peignez une image trop sombre de l'état de la POO moderne. Je dirais que cela a en fait réduit les coûts, rendu les grands projets logiciels gérables, et ainsi de suite. Cela ne signifie pas que cela a résolu le problème fondamental du désordre logiciel, et cela ne signifie pas que le développeur moyen est un expert en POO. Mais la modularisation de la fonction en composants-objets a certainement réduit la quantité de code spaghetti dans le monde.

Je peux penser à des dizaines de bibliothèques au sommet de ma tête qui sont magnifiquement réutilisables et qui ont économisé du temps et de l'argent qui ne peuvent jamais être calculés.

Mais dans la mesure où la POO a été une perte de temps, je dirais que c'est à cause du manque de formation des programmeurs, aggravée par la courbe d'apprentissage abrupte de l'apprentissage d'une cartographie de la POO spécifique à une langue. Certaines personnes "obtiennent" la POO et d'autres ne le feront jamais.

Je pense que l'utilisation d'objets de contexte opaques (HANDLEs dans Win32, FILE * s en C, pour ne citer que deux exemples bien connus - l'enfer, les HANDLEs vivent de l'autre côté de la barrière du mode noyau, et ça ne beaucoup plus encapsulé que cela) se trouve également dans le code de procédure; J'ai du mal à voir en quoi c'est quelque chose de particulier à la POO.

HANDLEs (et le reste de WinAPI) est POO! C ne supporte pas très bien la POO donc il n'y a pas de syntaxe spéciale mais cela ne veut pas dire qu'il n'utilise pas les mêmes concepts. WinAPI est dans tous les sens du terme un framework orienté objet.

Vous voyez, c'est le problème avec chaque discussion impliquant la POO ou des techniques alternatives: personne n'est clair sur la définition, tout le monde parle d'autre chose et donc aucun consensus ne peut être atteint. Cela me semble une perte de temps.

C'est un paradigme de programmation. Conçu pour nous permettre, à nous simples mortels, de décomposer un problème en morceaux plus petits et réalisables.

Si vous ne le trouvez pas utile .. Ne l'utilisez pas, ne payez pas pour la formation et soyez heureux.

D'un autre côté, je le trouve utile, alors je le ferai :)

Par rapport à la programmation procédurale directe, le premier principe fondamental de la POO est la notion de dissimulation et d'encapsulation d'informations. Cette idée conduit à la notion de classe qui sépare l'interface de l'implémentation. Ce sont des concepts extrêmement importants et la base pour mettre en place un cadre pour réfléchir à la conception des programmes d'une manière différente et meilleure (je pense). Vous ne pouvez pas vraiment argumenter contre ces propriétés - il n'y a pas de compromis et c'est toujours une manière plus propre de moduler les choses.

D'autres aspects de la POO, notamment l'héritage et le polymorphisme, sont également importants, mais comme d'autres l'ont fait allusion, ils sont souvent surutilisés. ie: Parfois, les gens utilisent l'héritage et / ou le polymorphisme parce qu'ils le peuvent, pas parce qu'ils auraient dû. Ce sont des concepts puissants et très utiles, mais qui doivent être utilisés à bon escient et ne sont pas des avantages automatiques gagnants de la POO.

Par rapport à la réutilisation. J'accepte que la réutilisation soit plus vendue pour la POO. C'est un effet secondaire possible d'objets bien définis, typiquement de classes plus primitives / génériques et est un résultat direct des concepts d'encapsulation et de masquage d'informations. Il est potentiellement plus facile à réutiliser car les interfaces de classes bien définies sont simplement plus claires et quelque peu auto-documentées.

Le problème avec la POO est qu'elle a été survendue.

Comme Alan Kay l'a conçu à l'origine, c'était une excellente alternative à la pratique antérieure d'avoir des données brutes et des routines globales.

Ensuite, certains types de consultants en gestion se sont accrochés et l'ont vendu comme le messie du logiciel, et, à la manière des lemmings, les universités et l'industrie ont dégringolé après.

Maintenant, ils tombent comme des lemmings après que d'autres bonnes idées aient été survendues, comme la programmation fonctionnelle.

Alors, que ferais-je différemment? Beaucoup, et j'ai écrit un livre à ce sujet. (Il est épuisé - je ne reçois pas un centime, mais vous pouvez toujours en obtenir des copies.) Amazon

Ma réponse constructive est de regarder la programmation non pas comme un moyen de modéliser les choses dans le monde réel, mais comme un moyen d'encoder les exigences.

C'est très différent et basé sur la théorie de l'information (à un niveau que tout le monde peut comprendre). Il dit que la programmation peut être considérée comme un processus de définition des langages, et la compétence en la matière est essentielle pour une bonne programmation.

Il élève le concept de langages spécifiques au domaine (DSL). Il est tout à fait d'accord avec DRY (ne vous répétez pas). Cela donne un grand coup de pouce à la génération de code. Il en résulte un logiciel avec beaucoup moins de structure de données que ce qui est typique pour les applications modernes.

Il cherche à revigorer l’idée que la voie à suivre passe par l’inventivité et que même les idées bien acceptées doivent être remises en question.

HANDLEs (et le reste de WinAPI) est POO!

Mais le sont-ils? Ils ne sont pas héréditaires, ils ne sont certainement pas substituables, ils manquent de classes bien définies ... Je pense qu'ils sont loin de "POO".

Avez-vous déjà créé une fenêtre avec WinAPI? Ensuite, vous devez savoir que vous définissez une classe ( RegisterClass), créez une instance de celle-ci ( CreateWindow), appelez des méthodes virtuelles ( WndProc) et des méthodes de classe de base ( DefWindowProc) et ainsi de suite. WinAPI prend même la nomenclature de SmallTalk OOP, appelant les méthodes «messages» (Window Messages).

Les poignées ne sont peut-être pas héritables, mais il existe finalen Java. Ils ne manquent pas de classe, ils sont un espace réservé pour la classe: c'est ce que signifie le mot «poignée». En regardant des architectures comme MFC ou .NET WinForms, il est immédiatement évident qu'à l'exception de la syntaxe, rien ne diffère beaucoup de WinAPI.

Oui, la POO n'a pas résolu tous nos problèmes, désolé. Nous travaillons cependant sur SOA qui résoudra tous ces problèmes.

La POO se prête bien à la programmation de structures informatiques internes telles que les "widgets" de l'interface graphique, où, par exemple, SelectList et TextBox peuvent être des sous-types de Item, qui a des méthodes communes telles que "déplacer" et "redimensionner".

Le problème, c'est que 90% d'entre nous travaillent dans le monde des affaires où nous travaillons avec des concepts commerciaux tels que la facture, l'employé, l'emploi, la commande. Celles - ci ne se prêtent pas si bien à la POO car les «objets» sont plus nébuleux, sujets à changement en fonction de la réingénierie métier, etc.

Le pire des cas est celui où OO est appliqué avec enthousiasme aux bases de données, y compris les énormes "améliorations" OO aux bases de données SQL - qui sont à juste titre ignorées, sauf par les noobs de base de données qui supposent qu'ils doivent être la bonne façon de faire les choses parce qu'elles sont plus récentes.

Dans mon expérience de la révision du code et de la conception de projets que j'ai traversés, la valeur de la POO n'est pas pleinement réalisée parce que beaucoup de développeurs n'ont pas correctement conceptualisé le modèle orienté objet dans leur esprit. Ainsi, ils ne programment pas avec un design OO, continuant très souvent à écrire du code procédural de haut en bas, faisant des classes un design assez plat . (si vous pouvez même appeler cela «design» en premier lieu)

Il est assez effrayant d'observer à quel point les collègues savent peu de choses sur ce qu'est une classe ou une interface abstraite, et encore moins de concevoir correctement une hiérarchie d'héritage pour répondre aux besoins de l'entreprise.

Cependant, quand une bonne conception OO est présente, c'est juste une joie pure de lire le code et de voir le code se mettre naturellement en place dans des composants / classes intuitifs. J'ai toujours perçu l'architecture et la conception du système comme la conception des différents départements et des emplois du personnel dans une entreprise - tous sont là pour accomplir un certain travail dans le grand schéma des choses, émettant la synergie nécessaire pour faire avancer l'organisation / le système.

Cela, bien sûr, est assez rare malheureusement. Tout comme le rapport entre les objets physiques magnifiquement conçus et horriblement conçus dans le monde, il en va de même pour l'ingénierie et la conception logicielles. Disposer des bons outils ne confère pas nécessairement de bonnes pratiques et des résultats.

Peut-être qu'un bonnet, un genou ou un arbre n'est pas une chaise mais ils sont tous ISittables.

Je pense que ces choses du monde réel sont des objets

Tu fais?

De quelles méthodes dispose une facture? Oh, attendez. Il ne peut pas se payer, il ne peut pas s'envoyer, il ne peut pas se comparer aux articles que le vendeur a effectivement livrés. Il n'a aucune méthode du tout; c'est totalement inerte et non fonctionnel. C'est un type d'enregistrement (une structure, si vous préférez), pas un objet.

De même les autres choses que vous mentionnez.

Ce n'est pas parce que quelque chose est réel que cela en fait un objet au sens OO du mot. Les objets OO sont un couplage particulier d'état et de comportement qui peuvent agir de leur propre chef. Ce n'est pas quelque chose d'abondant dans le monde réel.

J'écris du code OO depuis environ 9 ans. À part l'utilisation de la messagerie, il m'est difficile d'imaginer une autre approche. Le principal avantage que je vois tout à fait conforme à ce que CodingTheWheel a dit: la modularisation. OO m'amène naturellement à construire mes applications à partir de composants modulaires qui ont des interfaces propres et des responsabilités claires (c'est-à-dire un code faiblement couplé, hautement cohérent avec une séparation claire des préoccupations).

Je pense que là où OO s'effondre, c'est lorsque les gens créent des héritières de classe profondément imbriquées. Cela peut conduire à la complexité. Cependant, la prise en compte de la finalité commune dans une classe de base, puis la réutilisation dans d'autres classes descendantes est une chose profondément élégante, à mon humble avis!

En premier lieu, les observations sont quelque peu bâclées. Je n'ai pas de chiffres sur la productivité des logiciels et je n'ai aucune raison de croire qu'elle n'augmente pas. De plus, comme il y a beaucoup de gens qui abusent de l'OO, une bonne utilisation de l'OO ne provoquerait pas nécessairement une amélioration de la productivité même si l'OO était la meilleure chose depuis le beurre d'arachide. Après tout, un chirurgien du cerveau incompétent est susceptible d'être pire que rien du tout, mais un chirurgien compétent peut être inestimable.

Cela étant dit, l'OO est une manière différente d'organiser les choses, en attachant du code de procédure aux données plutôt que de faire fonctionner le code de procédure sur les données. Cela devrait être au moins une petite victoire en soi, car il existe des cas où l'approche OO est plus naturelle. Rien n'empêche quiconque d'écrire une API procédurale en C ++, après tout, et donc l'option de fournir des objets à la place rend le langage plus polyvalent.

De plus, il y a quelque chose que OO fait très bien: il permet à l'ancien code d'appeler automatiquement un nouveau code, sans changement. Si j'ai un code qui gère les choses de manière procédurale, et que j'ajoute un nouveau type de chose qui est similaire mais pas identique à un précédent, je dois changer le code de procédure. Dans un système OO, j'hérite de la fonctionnalité, change ce que j'aime, et le nouveau code est automatiquement utilisé en raison du polymorphisme. Cela augmente la localité des changements, et c'est une bonne chose.

L'inconvénient est qu'un bon OO n'est pas gratuit: il faut du temps et des efforts pour l'apprendre correctement. Comme c'est un mot à la mode majeur, il y a beaucoup de gens et de produits qui le font mal, juste pour le faire. Il n'est pas plus facile de concevoir une bonne interface de classe qu'une bonne API procédurale, et il existe toutes sortes d'erreurs faciles à commettre (comme des hiérarchies de classes profondes).

Considérez-le comme un type d'outil différent, pas nécessairement meilleur en général. Un marteau en plus d'un tournevis, par exemple. Peut-être finirons-nous par sortir de la pratique du génie logiciel en sachant quelle clé utiliser pour enfoncer la vis.

@Sean

Cependant, la prise en compte de la finalité commune dans une classe de base, puis la réutilisation dans d'autres classes descendantes est une chose profondément élégante, à mon humble avis!

Mais les développeurs «procéduraux» le font de toute façon depuis des décennies. La syntaxe et la terminologie peuvent différer, mais l'effet est identique. Il y a plus dans la POO que «réutiliser des fonctionnalités communes dans une classe de base», et je pourrais même aller jusqu'à dire que c'est difficile à décrire comme une POO du tout; appeler la même fonction à partir de différents bits de code est une technique aussi ancienne que la sous-procédure elle-même.

@Konrad

La POO peut être imparfaite et ce n'est certainement pas une solution miracle, mais cela rend les applications à grande échelle beaucoup plus simples car c'est un excellent moyen de réduire les dépendances

Tel est le dogme. Je ne vois pas ce qui rend la POO significativement meilleure à cet égard que la programmation procédurale d'autrefois. Chaque fois que j'effectue un appel de procédure, je m'isole des spécificités de l'implémentation.

Pour moi, il y a beaucoup de valeur dans la syntaxe OOP elle-même. Utiliser des objets qui tentent de représenter des choses réelles ou des structures de données est souvent beaucoup plus utile que d'essayer d'utiliser un tas de différentes fonctions plates (ou "flottantes") pour faire la même chose avec les mêmes données. Il y a un certain «flux» naturel vers les choses avec une bonne POO qui a juste plus de sens à lire, écrire et maintenir à long terme.

Peu importe qu'une facture ne soit pas vraiment un "objet" avec des fonctions qu'elle peut exécuter elle-même - l'instance d'objet peut exister uniquement pour exécuter des fonctions sur les données sans avoir à savoir quel type de données s'y trouve réellement. La fonction "facture.toJson ()" peut être appelée avec succès sans avoir à savoir quel type de données "facture" est - le résultat sera Json, peu importe s'il provient d'une base de données, XML, CSV ou même d'un autre objet JSON . Avec les fonctions procédurales, vous devez tout à coup en savoir plus sur vos données, et vous retrouver avec des fonctions comme "xmlToJson ()", "csvToJson ()", "dbToJson ()", etc. Cela devient finalement un désordre complet et un ÉNORME mal de tête si jamais vous changez le type de données sous-jacent.

Le but de la POO est de cacher l'implémentation réelle en l'abstruisant. Pour atteindre cet objectif, vous devez créer une interface publique. Pour faciliter votre travail lors de la création de cette interface publique et garder les choses SEC, vous devez utiliser des concepts tels que les classes abstraites, l'héritage, le polymorphisme et les modèles de conception.

Donc, pour moi, le véritable objectif primordial de la POO est de faciliter la maintenance et les modifications futures du code. Mais même au-delà de cela, cela peut vraiment simplifier beaucoup les choses lorsqu'il est fait correctement d'une manière que le code procédural ne pourrait jamais. Peu importe si cela ne correspond pas au «monde réel» - la programmation avec du code n'interagit pas avec les objets du monde réel de toute façon. La POO n'est qu'un outil qui rend mon travail plus facile et plus rapide - j'y vais n'importe quel jour.

@CodingTheWheel

Mais dans la mesure où la POO a été une perte de temps, je dirais que c'est à cause du manque de formation des programmeurs, aggravée par la courbe d'apprentissage abrupte de l'apprentissage d'une cartographie de la POO spécifique à une langue. Certaines personnes "obtiennent" la POO et d'autres ne le feront jamais.

Je ne sais pas si c'est vraiment surprenant, cependant. Je pense que les approches techniquement solides (LSP étant la chose évidente) sont difficiles à utiliser , mais si nous n'utilisons pas de telles approches, cela rend le code fragile et inextensible de toute façon (car nous ne pouvons plus raisonner à ce sujet). Et je pense que les résultats contre-intuitifs vers lesquels la POO nous amène rend pas surprenant que les gens ne le comprennent pas.

Plus important encore, étant donné que les logiciels sont déjà fondamentalement trop difficiles à écrire de manière fiable et précise pour les humains normaux, devrions-nous vraiment vanter une technique qui est constamment mal enseignée et semble difficile à apprendre? Si les avantages étaient évidents, il pourrait valoir la peine de persévérer malgré la difficulté, mais cela ne semble pas être le cas.

@Jeff

Par rapport à la programmation procédurale directe, le premier principe fondamental de la POO est la notion de dissimulation et d'encapsulation d'informations. Cette idée conduit à la notion de classe qui sépare l'interface de l'implémentation.

Laquelle a l'implémentation la plus cachée: les iostreams de C ++ ou les FILE * s de C?

Je pense que l'utilisation d'objets de contexte opaques (HANDLEs dans Win32, FILE * s en C, pour ne citer que deux exemples bien connus - l'enfer, les HANDLEs vivent de l'autre côté de la barrière du mode noyau, et ça ne beaucoup plus encapsulé que cela) se trouve également dans le code de procédure; J'ai du mal à voir en quoi c'est quelque chose de particulier à la POO.

Je suppose que cela peut expliquer en partie pourquoi j'ai du mal à voir les avantages: les parties qui sont évidemment bonnes ne sont pas spécifiques à la POO, alors que les parties qui sont spécifiques à la POO ne sont pas évidemment bonnes! (cela ne veut pas dire qu'ils sont nécessairement mauvais, mais plutôt que je n'ai pas vu la preuve qu'ils sont largement applicables et toujours bénéfiques).

Dans le seul blog de développement que j'ai lu, par ce gars de Joel-On-Software-Founder-of-SO, j'ai lu il y a longtemps que l'OO ne conduit pas à des augmentations de productivité. La gestion automatique de la mémoire le fait. Cool. Qui peut nier les données?

Je crois toujours que OO est à non-OO ce que la programmation avec des fonctions est à tout programmer en ligne.

(Et je devrais savoir, comme j'ai commencé avec GWBasic.) Lorsque vous refactorisez le code pour utiliser des fonctions, cela variable2654devient variable3de la méthode dans laquelle vous êtes. Ou, mieux encore, il a un nom que vous pouvez comprendre, et si la fonction est courte , ça s'appelle value et c'est suffisant pour une pleine compréhension.

Lorsque le code sans fonctions devient un code avec des méthodes, vous pouvez supprimer des kilomètres de code.

Lorsque vous codez refactoring pour être vraiment OO, b, c, qet Zdevenir this, this, thiset this. Et comme je ne crois pas à l'utilisation du thismot - clé, vous pouvez supprimer des miles de code. En fait, vous pouvez le faire même si vous utilisez this.

Je ne pense pas que OO soit une métaphore naturelle.

Je ne pense pas non plus que le langage soit une métaphore naturelle, et je ne pense pas non plus que les «odeurs» de Fowler valent mieux que de dire «ce code a mauvais goût». Cela dit, je pense que OO ne concerne pas les métaphores naturelles et les gens qui pensent que les objets surgissent juste à vous manquent fondamentalement le point. Vous définissez l'univers des objets, et de meilleurs univers d'objets aboutissent à un code plus court, plus facile à comprendre, qui fonctionne mieux, ou tous ces éléments (et certains critères que j'oublie). Je pense que les personnes qui utilisent les objets naturels du client / domaine comme objets de programmation n'ont pas le pouvoir de redéfinir l'univers.

Par exemple, lorsque vous effectuez un système de réservation aérienne, ce que vous appelez une réservation peut ne pas correspondre du tout à une réservation légale / commerciale.

Certains des concepts de base sont des outils vraiment sympas

Je pense que la plupart des gens exagèrent avec cette chose "quand vous avez un marteau, ce sont tous des clous". Je pense que l'autre côté de la pièce / du miroir est tout aussi vrai: lorsque vous avez un gadget comme le polymorphisme / l'héritage, vous commencez à trouver des utilisations où il tient comme un gant / une chaussette / une lentille de contact. Les outils d'OO sont très puissants. L'héritage unique est, je pense, absolument nécessaire pour que les gens ne s'emballent pas, mon propre logiciel d'héritage multiple ne résiste pas.

Quel est l'intérêt de la POO?

Je pense que c'est un excellent moyen de gérer une base de code absolument massive. Je pense que cela vous permet d'organiser et de réorganiser votre code et de vous donner un langage pour le faire (au-delà du langage de programmation dans lequel vous travaillez), et de modulariser le code d'une manière assez naturelle et facile à comprendre.

La POO est destinée à être mal comprise par la majorité des développeurs

C'est parce que c'est un processus révélateur comme la vie: vous comprenez de plus en plus OO avec l'expérience, et commencez à éviter certains modèles et à en utiliser d'autres à mesure que vous devenez plus sage. L'un des meilleurs exemples est que vous arrêtez d'utiliser l'héritage pour les classes que vous ne contrôlez pas et que vous préférez plutôt le modèle Facade .

Concernant votre mini-essai / question

Je voulais mentionner que vous avez raison. La réutilisation est une chimère, pour la plupart. Voici une citation d'Anders Hejilsberg sur ce sujet (brillant) d'ici :

Si vous demandez aux programmeurs débutants d'écrire un contrôle de calendrier, ils se disent souvent: "Oh, je vais écrire le meilleur contrôle de calendrier au monde! Il va être polymorphe par rapport au type de calendrier. Il aura des afficheurs, et les mungers, et ceci, cela et l'autre. " Ils doivent expédier une application de calendrier dans deux mois. Ils mettent toute cette infrastructure en place dans le contrôle, puis passent deux jours à écrire une application de calendrier merdique en plus. Ils penseront: "Dans la prochaine version de l'application, je vais faire beaucoup plus."

Une fois qu'ils commencent à réfléchir à la façon dont ils vont réellement mettre en œuvre toutes ces autres concrétisations de leur conception abstraite, cependant, il s'avère que leur conception est complètement fausse. Et maintenant, ils se sont peints dans un coin, et ils doivent tout jeter. J'ai vu cela encore et encore. Je suis fermement convaincu d'être minimaliste. À moins que vous ne résolviez réellement le problème général, n'essayez pas de mettre en place un cadre pour résoudre un problème spécifique, car vous ne savez pas à quoi devrait ressembler ce cadre.

Avez-vous déjà créé une fenêtre avec WinAPI?

Plus de fois que je ne m'en souviens.

Ensuite, vous devez savoir que vous définissez une classe (RegisterClass), créez une instance de celle-ci (CreateWindow), appelez des méthodes virtuelles (WndProc) et des méthodes de classe de base (DefWindowProc) et ainsi de suite. WinAPI prend même la nomenclature de SmallTalk OOP, appelant les méthodes «messages» (Window Messages).

Ensuite, vous saurez également qu'il ne transmet pas de messages par lui-même, ce qui est un grand vide béant. Il a également un sous-classement merdique.

Les poignées ne sont peut-être pas héritables, mais alors, il y a final en Java. Ils ne manquent pas de classe, ils sont un espace réservé pour la classe: c'est ce que signifie le mot «poignée». En regardant des architectures comme MFC ou .NET WinForms, il est immédiatement évident qu'à l'exception de la syntaxe, rien ne diffère beaucoup de WinAPI.

Ils ne sont pas héréditaires ni dans l'interface ni dans l'implémentation, ils ne peuvent être substitués au minimum et ils ne sont pas substantiellement différents de ce que les codeurs procéduraux font depuis toujours.

Est-ce vraiment ça? Les meilleurs morceaux de POO ne sont que ... du code procédural traditionnel? C'est ça le gros problème?

Je suis entièrement d'accord avec la réponse d' InSciTek Jeff , je vais juste ajouter les améliorations suivantes:

• Masquage et encapsulation des informations: Critique pour tout code maintenable. Peut être fait en faisant attention dans n'importe quel langage de programmation, ne nécessite pas de fonctionnalités OO, mais cela rendra votre code légèrement semblable à OO.
• Héritage: Il existe un domaine d'application important pour lequel toutes ces relations OO sont une sorte de et contiennent un ajustement parfait: les interfaces utilisateur graphiques. Si vous essayez de créer des interfaces graphiques sans prise en charge du langage OO, vous finirez par créer des fonctionnalités de type OO de toute façon, et c'est plus difficile et plus sujet aux erreurs sans prise en charge du langage. Glade (récemment) et X11 Xt (historiquement) par exemple.

Utiliser les fonctionnalités OO (en particulier les hiérarchies abstraites profondément imbriquées), quand cela ne sert à rien, est inutile. Mais pour certains domaines d'application, il y a vraiment un point.

Je pense que la qualité la plus bénéfique de la POO est le masquage / la gestion des données. Cependant, il y a BEAUCOUP d'exemples où la POO est mal utilisée et je pense que c'est là que la confusion entre en jeu.

Ce n'est pas parce que vous pouvez transformer quelque chose en objet que vous devriez le faire. Cependant, si cela rend votre code plus organisé / plus facile à lire, vous devriez certainement le faire.

Un excellent exemple pratique où la POO est très utile est avec une classe "produit" et des objets que j'utilise sur notre site Web. Étant donné que chaque page est un produit et que chaque produit a des références à d'autres produits, il peut être très difficile de savoir à quel produit les données que vous avez se réfèrent. Cette variable "strURL" est-elle le lien vers la page courante, ou vers la page d'accueil, ou vers la page de statistiques? Bien sûr, vous pouvez créer toutes sortes de variables différentes faisant référence aux mêmes informations, mais proCurrentPage-> strURL, est beaucoup plus facile à comprendre (pour un développeur).

De plus, attacher des fonctions à ces pages est beaucoup plus propre. Je peux faire proCurrentPage-> CleanCache (); Suivi de proDisplayItem-> RenderPromo (); Si j'appelais simplement ces fonctions et que je supposais que les données actuelles étaient disponibles, qui sait quel genre de mal se produirait. De plus, si je devais passer les bonnes variables dans ces fonctions, je reviens au problème d'avoir toutes sortes de variables pour les différents produits.

Au lieu de cela, en utilisant des objets, toutes mes données produit et mes fonctions sont claires et faciles à comprendre.

Toutefois. Le gros problème avec la POO est quand quelqu'un croit que TOUT devrait être POO. Cela crée beaucoup de problèmes. J'ai 88 tables dans ma base de données. Je n'ai que 6 cours environ, et peut-être que je devrais en avoir environ 10. Je n'ai certainement pas besoin de 88 cours. La plupart du temps, accéder directement à ces tables est parfaitement compréhensible dans les circonstances où je l'utilise, et la POO rendrait en fait plus difficile / fastidieux d'accéder aux fonctionnalités de base de ce qui se passe.

Je crois qu'un modèle hybride d'objets où utile et procédural là où c'est pratique est la méthode de codage la plus efficace. C'est dommage que nous ayons toutes ces guerres de religion où les gens préconisent d'utiliser une méthode au détriment des autres. Ils sont tous les deux bons et ils ont tous les deux leur place. La plupart du temps, les deux méthodes sont utilisées dans tous les grands projets (dans certains projets plus petits, un seul objet ou quelques procédures peuvent suffire).

Je n'aime pas autant la réutilisation que la lisibilité. Ce dernier signifie que votre code est plus facile à modifier. Cela seul vaut de l'or dans le domaine de la création de logiciels.

Et OO est un moyen très efficace de rendre vos programmes lisibles. Réutiliser ou ne pas réutiliser.

"Le monde réel n'est pas" OO ","

Vraiment? Mon monde est plein d'objets. J'en utilise un maintenant. Je pense qu'avoir des "objets" logiciels modélisant les objets réels n'est peut-être pas une si mauvaise chose.

Les conceptions OO pour des choses conceptuelles (comme Windows, pas les fenêtres du monde réel, mais les panneaux d'affichage sur mon écran d'ordinateur) laissent souvent beaucoup à désirer. Mais pour des choses du monde réel comme les factures, les commandes d'expédition, les réclamations d'assurance et autres, je pense que ces choses du monde réel sont des objets. J'ai une pile sur mon bureau, donc elles doivent être réelles.

Le but de la POO est de donner au programmeur un autre moyen de décrire et de communiquer une solution à un problème de code aux machines et aux personnes. La partie la plus importante de cela est la communication avec les gens. La POO permet au programmeur de déclarer ce qu'ils signifient dans le code grâce à des règles qui sont appliquées dans le langage OO.

Contrairement à de nombreux arguments sur ce sujet, les concepts POO et OO sont omniprésents dans tout le code, y compris le code dans des langages non OOP tels que C. De nombreux programmeurs avancés non OO se rapprocheront des fonctionnalités des objets même dans les langages non OO.

Avoir OO intégré dans le langage donne simplement au programmeur un autre moyen d'expression.

La plus grande partie de l'écriture de code n'est pas la communication avec la machine, cette partie est facile, la plus grande partie est la communication avec les programmeurs humains.