Quel est le sharepoint la POO?

Pour autant que je sache, malgré les innombrables millions de dollars consacrés à l’éducation du POO, aux langues et aux outils, la POO n’a pas amélioré la productivité des développeurs ni la fiabilité des logiciels, ni réduit les coûts de développement. Peu de personnes utilisent la POO de manière rigoureuse (peu de personnes adhèrent ou comprennent des principes tels que le LSP); Il semble y avoir peu d’uniformité ou de cohérence avec les approches que les gens adoptent pour modéliser les domaines problématiques. Trop souvent, la classe est simplement utilisée 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ù le véritable sous-typage substituable a joué un rôle précieux dans l’application, ceux-ci ont été plutôt exceptionnels. En général, bien que beaucoup de discours soient donnés pour parler de «réutilisation», la réalité est que, à moins qu’un morceau de code ne fasse exactement ce que vous voulez, il y a très peu de «réutilisation» rentable. Il est extrêmement difficile de concevoir des cours pour qu’ils soient extensibles de la bonne manière . Le coût de l’extension est donc tellement élevé que la «réutilisation» ne 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 des choses avec une taxonomie de classe – me semble très fondamentalement erronée (je peux m’asseoir sur une table, une souche d’arbre, un capot de voiture , les genoux de quelqu’un – mais pas 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 le logiciel?

Il n’y a aucune preuve empirique suggérant que l’orientation des objects 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 qu’OO n’est pas plus adapté que d’autres approches.

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

Il ne suffit pas d’adopter les méthodes OO et d’exiger que les développeurs 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 vient de “Sur la facilité d’utilisation 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 personnes 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 un thème entier sur les études OO), et d’après ce que j’ai lu, rien n’indique que l’approche OO soit plus naturelle que l’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 des choses avec une taxonomie de classe – me semble très fondamentalement erronée

Bien que cela soit vrai et a été observé par d’autres personnes (prenez Stepanov, l’inventeur du TSL), le rest est un non-sens. La POO peut être imparfaite et ce n’est certainement pas une solution miracle, mais elle simplifie considérablement les applications à grande échelle, car c’est un excellent moyen de réduire les dépendances. Bien sûr, cela ne vaut que pour la «bonne» conception de la POO. Le design bâclé ne donnera aucun avantage. Mais une bonne conception découplée peut très bien être modélisée à l’aide de la POO et ne pas bien utiliser d’autres techniques.

Il existe de bien meilleurs modèles, plus universels ( le modèle type de Haskell vient à l’esprit), mais ceux-ci sont 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 simplement utilisée 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. Ce n’est pas une programmation orientée object. C’est la programmation par object et la programmation centrée sur les données. Au cours de mes 10 années de travail avec OO Languages, je vois surtout des gens qui font de la programmation par objects. OBP se décompose très rapidement à mon humble avis puisque vous obtenez essentiellement le pire des deux mots: 1) Programmation procédurale sans respecter la méthodologie de programmation structurée éprouvée et 2) POO sans respecter la méthodologie éprouvée de la POO.

OOP fait bien est une belle chose. Cela rend les problèmes très difficiles faciles à résoudre, et pour les non-initiés (sans chercher à paraître pompeux), cela peut presque sembler magique. Cela dit, la POO n’est qu’un outil dans la boîte à outils des méthodologies de programmation. Ce n’est pas la finalité de toute la méthodologie. Il se trouve que cela convient parfaitement aux applications professionnelles de grande taille.

La plupart des développeurs qui travaillent dans des langages OOP utilisent des exemples de POO exécutés directement dans les frameworks et les types qu’ils utilisent au quotidien, mais ils ne sont tout simplement pas au courant. Voici quelques exemples très simples: ADO.NET, Hibernate / NHibernate, Cadres de journalisation, divers types de collections de langages, la stack ASP.NET, la stack JSP, etc.

La réutilisation ne devrait pas être un objective de la POO – ou tout autre paradigme à cet égard.

La réutilisation est un effet secondaire d’un bon design et d’un bon niveau d’abstraction. Le code permet la réutilisation en faisant quelque chose d’utile, mais en ne faisant pas trop pour le rendre inflexible. Peu importe si le code est OO ou non – nous réutilisons ce qui fonctionne et n’est pas sortingvial pour nous-mêmes. C’est du pragmatisme.

La pensée d’OO comme nouvelle façon de réutiliser par inheritance est fondamentalement erronée. Comme vous le constatez, les violations du LSP abondent. Au lieu de cela, OO est considéré comme une méthode de gestion de la complexité d’un domaine problématique. L’objective est la maintenabilité d’un système au fil du temps. L’outil principal 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 “Ceci ne devrait être modifié qu’en utilisant …” imposées par le compilateur, plutôt que la révision du code.

Je suis sûr que vous en conviendrez, cela 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.

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

Je pense à des dizaines de bibliothèques sur le dessus 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 de programmeur, aggravé par la courbe d’apprentissage abrupte de l’apprentissage d’un mappage de POO spécifique au langage. Certaines personnes “obtiennent” la POO et d’autres ne le feront jamais.

Je pense que l’utilisation d’objects de contexte opaques (HANDLE dans Win32, FILE * en C, pour nommer deux exemples bien connus – bonjour, les HANDLEs vivent de l’autre côté de la barrière en mode kernel, et ça ne se voit pas vraiment). beaucoup plus encapsulé que cela) se trouve également dans le code de procédure; J’ai du mal à voir comment c’est quelque chose de particulier pour la POO.

HANDLE (et le rest de WinAPI) est OOP! C ne supporte pas très bien la POO donc il n’y a pas de syntaxe particulière mais cela ne signifie pas qu’elle n’utilise pas les mêmes concepts. WinAPI est dans tous les sens du terme un cadre orienté object.

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

C’est un paradigme de programmation. Conçu pour simplifier la tâche à de simples mortels pour décomposer un problème en pièces plus petites et exploitables.

Si vous ne le trouvez pas utile .. Ne l’utilisez pas, ne payez pas pour l’entraînement et soyez heureux.

Je trouve par contre cela utile, alors je vais le faire 🙂

Par rapport à la programmation procédurale directe, le premier principe fondamental de la POO est la notion de masquage et d’encapsulation de l’information. 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 de reflection sur la conception des programmes d’une manière différente et, à mon avis, meilleure. Vous ne pouvez pas vraiment vous opposer à ces propriétés – il n’y a pas de compromis à faire et c’est toujours une façon plus propre de moduler les choses.

D’autres aspects de la POO, y compris l’inheritance et le polymorphism, sont également importants, mais comme d’autres l’ont mentionné, ceux-ci sont couramment utilisés. C’est-à-dire: Parfois, les gens utilisent l’inheritance et / ou le polymorphism parce qu’ils le peuvent, et non parce qu’ils le devraient. Ce sont des concepts puissants et très utiles, mais ils doivent être utilisés avec sagesse et ne sont pas des avantages automatiques de la POO.

Relatif à la réutilisation. Je conviens que la réutilisation est vendue pour la POO. C’est un effet secondaire possible d’objects bien définis, généralement de classes plus primitives / génériques, résultant directement des concepts d’encapsulation et de dissimulation d’informations. Il est potentiellement plus facile d’être réutilisé 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’il a été survendu.

Comme Alan Kay l’a initialement conçu, c’était une excellente alternative à la pratique antérieure consistant à disposer de données brutes et de routines globales.

Ensuite, certains types de consultants en gestion se sont emparés de ce logiciel et l’ont vendu en tant que messie du logiciel.

Maintenant, ils sont en train de dégringoler après avoir survécu à d’autres bonnes idées, comme la functional programming.

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

Ma réponse constructive consiste à considérer la programmation non pas comme un moyen de modéliser les choses dans le monde réel, mais plutôt comme un moyen de coder 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 langues, et que les compétences nécessaires à cette fin sont essentielles à une bonne programmation.

Il élève le concept de langage spécifique au domaine (DSL). Il est catégorique avec DRY (ne vous répétez pas). Il donne un gros coup de pouce à la génération de code. Il en résulte un logiciel avec une structure de données considérablement inférieure à celle des applications modernes.

Il cherche à revigorer l’idée que la voie à suivre réside dans l’inventivité et que même des idées bien acceptées doivent être remises en question.

HANDLEs (et le rest de WinAPI) est OOP!

Sont-ils, cependant? Ils ne sont pas héritables, ils ne sont certainement pas substituables, ils manquent de classes bien définies… Je pense qu’ils sont loin de «OOP».

Avez-vous déjà créé une fenêtre avec WinAPI? Vous devez ensuite savoir que vous définissez une classe ( RegisterClass ), créez-en une ( CreateWindow ), appelez les méthodes virtuelles ( WndProc ) et les méthodes de classe de base ( DefWindowProc ), etc. 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 y a final Java. Ils ne manquent pas de cours, ils sont un espace réservé pour la classe: c’est ce que signifie le mot «gérer». En regardant les architectures comme MFC ou .NET WinForms, il est immédiatement évident que, à part la syntaxe, rien n’est différent de WinAPI.

Oui, OOP n’a pas résolu tous nos problèmes, désolé pour ça. Nous travaillons toutefois sur SOA, ce qui résoudra tous ces problèmes.

La POO se prête bien à la programmation de structures informatiques internes telles que les “widgets” d’interface graphique, par exemple SelectList et TextBox peuvent être des sous-types de Item, qui ont des méthodes communes telles que “move” et “resize”.

Le problème est que 90% de nous travaillons dans le monde des affaires où nous travaillons avec des concepts commerciaux tels que Facture, Employé, Emploi, Ordre. Celles ci ne se prêtent pas très bien à la POO, car les «objects» sont plus nébuleux, sujets à changement en fonction de la réorganisation de l’entreprise, etc.

Le pire des cas est celui où OO s’applique avec enthousiasme aux bases de données, y compris les “améliorations” des bases de données SQL, qui sont ignorées, sauf par les noobs de bases de données.

Dans mon expérience de révision du code et de la conception de projets que j’ai connus, la valeur de la POO n’est pas pleinement exploitée car beaucoup de développeurs n’ont pas correctement conceptualisé le modèle orienté object . Ainsi, ils ne programment pas avec OO Design, continuant très souvent à écrire du code procédural de haut en bas, ce qui rend les classes assez plates . (si vous pouvez même appeler cela “design” en premier lieu)

Il est assez effrayant d’observer comment peu de collègues savent ce qu’est une classe abstraite ou une interface, et encore moins de concevoir correctement une hiérarchie d’inheritance en fonction des besoins de l’entreprise.

Cependant, en présence d’une bonne conception OO, il est tout simplement agréable de lire le code et de voir le code s’intégrer naturellement dans des composants / classes intuitifs. J’ai toujours perçu l’architecture et la conception des systèmes comme la conception des divers départements et des postes de travail dans une entreprise. Tous sont là pour accomplir un certain travail dans le grand ensemble, en émettant la synergie nécessaire pour propulser l’organisation.

Cela, bien sûr, est assez rare malheureusement. Comme dans le monde, le rapport entre des objects physiques magnifiquement conçus et des objects conçus de façon horrible, on peut en dire autant de l’ingénierie et de la conception logicielles. Avoir les bons outils à sa disposition ne confère pas nécessairement de bonnes pratiques et des résultats.

Peut-être qu’un capot, des genoux ou un arbre ne sont pas une chaise mais ils sont tous ISittable.

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

Tu fais?

Quelles sont les méthodes d’une facture? Oh, attendez. Il ne peut pas se payer, il ne peut pas s’envoyer lui-même, il ne peut pas se comparer aux articles que le fournisseur a effectivement livrés. Il n’y a pas de 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 object.

De même les autres choses que vous mentionnez.

Le fait que quelque chose soit réel ne fait pas de lui un object au sens du terme OO. Les objects OO sont un couplage particulier d’états et de comportements pouvant agir de leur propre chef. Ce n’est pas quelque chose qui est abondant dans le monde réel.

J’écris le code OO depuis environ 9 ans. En dehors de la messagerie, il m’est difficile d’imaginer une autre approche. Le principal avantage que je vois totalement en accord avec ce que dit CodingTheWheel: la modularisation. OO m’amène naturellement à créer mes applications à partir de composants modulaires dotés d’interfaces propres et de responsabilités claires (par exemple, un code hautement cohérent et à faible séparation, avec une séparation claire des problèmes).

Je pense que OO se décompose lorsque les gens créent des hiérarchies de classes profondément nestedes. Cela peut mener à la complexité. Cependant, en prenant en compte la finalité commune dans une classe de base, réutiliser celle-ci dans d’autres classes de descendants est une chose très élégante, à mon humble avis!

En premier lieu, les observations sont quelque peu négligées. Je n’ai pas de chiffres sur la productivité des logiciels et je n’ai aucune raison de croire que cela ne va pas augmenter. De plus, comme il y a beaucoup de gens qui abusent de l’OO, le bon usage de l’OO n’entraînerait pas nécessairement une amélioration de la productivité, même si OO était la meilleure chose depuis le beurre d’arachide. Après tout, un chirurgien cérébral incompétent est susceptible d’être pire que rien, mais un chirurgien compétent peut être inestimable.

Cela étant dit, OO est une façon différente d’organiser les choses, en attachant un code de procédure aux données plutôt qu’un code de procédure opérant sur des données. Cela devrait être au moins une petite victoire en soi, car il y a des cas où l’approche OO est plus naturelle. Il n’y a rien qui empêche quiconque d’écrire une API procédurale en C ++, après tout, la possibilité de fournir des objects rend le langage plus polyvalent.

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

L’inconvénient est que le bon OO n’est pas gratuit: il faut du temps et des efforts pour l’apprendre correctement. Comme c’est un mot à la mode, 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 y a toutes sortes d’erreurs faciles à faire (comme les hiérarchies de classes profondes).

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

@Sean

Cependant, en prenant en compte la finalité commune dans une classe de base, réutiliser celle-ci dans d’autres classes de descendants est une chose très élégante, à mon humble avis!

Mais les développeurs “procéduraux” le font depuis des décennies. La syntaxe et la terminologie peuvent différer, mais l’effet est identique. La POO ne se limite pas à “réutiliser des fonctionnalités communes dans une classe de base”, et j’irais même jusqu’à dire que cela est difficile à décrire comme une POO. 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 elle simplifie considérablement les applications à grande échelle, car c’est un excellent moyen de réduire les dépendances.

C’est le dogme. Je ne vois pas ce qui rend la POO nettement meilleure à cet égard que la programmation procédurale de jadis. Chaque fois que je fais un appel de procédure, je m’isole des spécificités de l’implémentation.

Pour moi, la syntaxe de la POO a beaucoup de valeur. L’utilisation d’objects qui tentent de représenter des objects réels ou des structures de données est souvent beaucoup plus utile que d’essayer d’utiliser plusieurs fonctions plates (ou flottantes) différentes pour faire la même chose avec les mêmes données. Il y a un certain “stream” naturel vers les choses avec une bonne POO qui a plus de sens pour lire, écrire et maintenir à long terme.

Peu importe qu’une facture ne soit pas vraiment un “object” avec des fonctions qu’elle peut exécuter elle-même – l’instance d’object peut exister uniquement pour exécuter des fonctions sur les données sans avoir à savoir quel type de données est réellement présent. La fonction “invoice.toJson ()” peut être appelée avec succès sans avoir à connaître le type de données “facturation” – le résultat sera Json, qu’il provienne d’une firebase database, XML, CSV ou même d’un autre object JSON . Avec les fonctions procédurales, vous devez soudainement en savoir plus sur vos données et vous retrouver avec des fonctions telles que “xmlToJson ()”, “csvToJson ()”, “dbToJson ()”, etc. Maux de tête énormes si vous changez le type de données sous-jacent.

Le but de la POO est de masquer la mise en œuvre réelle en l’abstenant. Pour atteindre cet objective, vous devez créer une interface publique. Pour faciliter votre travail lors de la création de cette interface publique et de la gestion des données, vous devez utiliser des concepts tels que les classes abstraites, l’inheritance, le polymorphism et les modèles de conception.

Pour moi, le véritable objective primordial de la POO est de faciliter la maintenance et les modifications futures du code. Mais même au-delà, cela peut vraiment simplifier les choses quand elles sont effectuées correctement, comme le code procédural ne le pourrait jamais. Peu importe qu’il ne corresponde pas au “monde réel”, la programmation avec du code n’interagit pas avec les objects du monde réel. La POO est juste un outil qui rend mon travail plus facile et plus rapide – je le ferai chaque 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 de programmeur, aggravé par la courbe d’apprentissage abrupte de l’apprentissage d’un mappage de POO spécifique au langage. Certaines personnes “obtiennent” la POO et d’autres ne le feront jamais.

Je ne sais pas si c’est vraiment surprenant. Je pense que les approches techniquement saines (le LSP étant la chose la plus é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). Et je pense que les résultats contre-intuitifs auxquels nous sums confrontés nous amènent à penser que les gens ne les prennent pas en main.

Plus important encore, étant donné que les logiciels sont déjà fondamentalement trop difficiles à écrire pour les humains normaux, devrions-nous vraiment faire l’éloge d’une technique régulièrement mal enseignée et difficile à apprendre? Si les avantages étaient clairs, il pourrait être utile 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 masquage et d’encapsulation de l’information. Cette idée conduit à la notion de classe qui sépare l’interface de l’implémentation.

Quelle est l’implémentation la plus cachée: les iostreams de C ++, ou les fichiers FILE * de C?

Je pense que l’utilisation d’objects de contexte opaques (HANDLE dans Win32, FILE * en C, pour nommer deux exemples bien connus – bonjour, les HANDLEs vivent de l’autre côté de la barrière en mode kernel, et ça ne se voit pas vraiment). beaucoup plus encapsulé que cela) se trouve également dans le code de procédure; J’ai du mal à voir comment c’est quelque chose de particulier pour la POO.

Je suppose que cela peut être une des raisons pour lesquelles j’ai du mal à voir les avantages: les parties qui sont manifestement bonnes ne sont pas spécifiques à la POO, alors que les parties spécifiques à la POO ne sont évidemment pas 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 systématiquement bénéfiques).

Dans le seul blog de développement que j’ai lu, par le fondateur de Joel-On-Software-Founder-of-SO, j’ai lu il y a longtemps que OO n’entraînait pas d’augmentation de la productivité. La gestion automatique de la mémoire le fait. Cool. Qui peut refuser les données?

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

(Et je devrais le savoir, comme j’ai commencé avec GWBasic.) Lorsque vous refactorez du code pour utiliser des fonctions, la variable2654 devient variable3 de la méthode dans laquelle vous vous trouvez. Ou mieux encore, elle a un nom que vous pouvez comprendre et si la fonction c’est court, ça s’appelle la value et c’est suffisant pour la compréhension totale.

Lorsque le code sans fonctions devient du code avec des méthodes, vous pouvez supprimer des miles de code.

Lorsque vous refactorez le code pour qu’il soit vraiment OO, b , c , q et Z deviennent this , this , this et this . Et comme je ne crois pas en l’utilisation de this mot this clé, vous pouvez supprimer des miles de code. En fait, vous pouvez le faire même si vous l’utilisez.

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

Je ne pense pas non plus que la langue 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 un mauvais goût». Cela dit, je pense que OO ne concerne pas les métaphores naturelles et que les personnes qui pensent que les objects sortent de chez vous manquent fondamentalement le point. Vous définissez l’univers de l’object, et de meilleurs univers d’object génèrent 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 objects naturels des clients / domaines en tant qu’objects de programmation manquent le pouvoir de redéfinir l’univers.

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

Certains des concepts de base sont des outils vraiment cool

Je pense que la plupart des gens exagèrent avec tout cela “quand vous avez un marteau, ils sont tous des clous”. Je pense que le revers de la médaille ou du miroir est tout aussi vrai: lorsque vous avez un gadget comme le polymorphism / inheritance, vous commencez à trouver des utilisations qui s’adaptent comme un gant / une chaussette / une lentille de contact. Les outils d’OO sont très puissants. Je pense que l’inheritance simple est absolument nécessaire pour que les gens ne se laissent pas emporter, sans tenir compte de mon propre logiciel multi-inheritance.

Quel est le sharepoint 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 vous donne un langage pour le faire (au-delà du langage de programmation dans lequel vous travaillez), et 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 OO de plus en plus avec l’expérience, et commencez à éviter certains schémas et à employer les autres plus sage. L’un des meilleurs exemples est que vous arrêtez d’utiliser l’inheritance pour les classes que vous ne contrôlez pas et préférez plutôt le motif Facade .

Concernant votre mini-essai / question

Je voulais mentionner que tu as raison. La réutilisabilité est un rêve, pour la plupart. Voici une citation d’Anders Hejilsberg sur ce sujet (génial) d’ici :

Si vous demandez aux programmeurs débutants d’écrire un calendrier, ils se disent souvent: «Oh, je vais écrire le meilleur contrôle de calendrier au monde! Il sera 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 ont mis toute cette infrastructure en place dans le contrôle, puis ont passé deux jours à rédiger une application de calendrier de mauvaise qualité. Ils penseront: “Dans la prochaine version de l’application, je vais faire beaucoup plus.”

Une fois qu’ils commencent à réfléchir à la manière dont ils vont réellement mettre en œuvre toutes ces concrétisations de leur dessin abstrait, 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 ça encore et encore. Je crois fermement que je suis minimaliste. À moins que vous ne résolviez le problème général, n’essayez pas de mettre en place un cadre pour en résoudre un, car vous ne savez pas à quoi doit ressembler ce cadre.

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

Plus de fois que je tiens à me souvenir.

Vous devez ensuite savoir que vous définissez une classe (RegisterClass), créez-en une (CreateWindow), appelez les méthodes virtuelles (WndProc) et les méthodes de classe de base (DefWindowProc), etc. WinAPI prend même la nomenclature de SmallTalk OOP, appelant les méthodes «messages» (Window Messages).

Ensuite, vous saurez également qu’il n’ya aucun envoi de message, ce qui est un grand vide. Il a aussi un sous-classement de merde.

Les poignées ne sont peut-être pas héritables, mais il y a finalement Java. Ils ne manquent pas de cours, ils sont un espace réservé pour la classe: c’est ce que signifie le mot «gérer». En regardant les architectures comme MFC ou .NET WinForms, il est immédiatement évident que, à part la syntaxe, rien n’est différent de WinAPI.

Ils ne sont pas héritables ni dans l’interface ni dans la mise en œuvre, mais sont peu substituables, et ils ne sont pas sensiblement différents de ce que les codeurs procéduraux ont fait depuis toujours.

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

Je suis tout à fait d’accord avec la réponse d’ InSciTek Jeff , j’appendai simplement les améliorations suivantes:

  • Masquage et encapsulation d’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 OO-like.
  • Héritage: il existe un domaine d’application important pour lequel tous les objects OO sont un type et contiennent des relations parfaitement adaptées: 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, et c’est plus difficile et plus sujet aux erreurs sans prise en charge linguistique. Glade (récemment) et X11 Xt (historiquement) par exemple.

L’utilisation de fonctionnalités OO (en particulier les hiérarchies abstraites profondément nestedes), lorsqu’il n’y a pas de point, est inutile. Mais pour certains domaines d’application, il y a vraiment un point.

Je pense que la meilleure qualité de la POO est la dissimulation / 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 intervient.

Ce n’est pas parce que vous pouvez faire quelque chose dans un object que vous devriez le faire. Cependant, si vous le faites, votre code sera mieux organisé / plus facile à lire.

Un excellent exemple pratique où la POO est très utile concerne la classe “produit” et les objects que j’utilise sur notre site Web. Comme chaque page est un produit et que chaque produit comporte des références à d’autres produits, il peut être très difficile de savoir à quel produit les données que vous vous référez font référence. Cette variable “strURL” est-elle le lien vers la page en cours, ou vers la page d’accueil ou vers la page de statistiques? Sure you could make all kinds of different variable that refer to the same information, but proCurrentPage->strURL, is much easier to understand (for a developer).

In addition, attaching functions to those pages is much cleaner. I can do proCurrentPage->CleanCache(); Followed by proDisplayItem->RenderPromo(); If I just called those functions and had it assume the current data was available, who knows what kind of evil would occur. Also, if I had to pass the correct variables into those functions, I am back to the problem of having all kinds of variables for the different products laying around.

Instead, using objects, all my product data and functions are nice and clean and easy to understand.

Toutefois. The big problem with OOP is when somebody believes that EVERYTHING should be OOP. This creates a lot of problems. I have 88 tables in my database. I only have about 6 classes, and maybe I should have about 10. I definitely don’t need 88 classes. Most of the time directly accessing those tables is perfectly understandable in the circumstances I use it, and OOP would actually make it more difficult/tedious to get to the core functionality of what is occurring.

I believe a hybrid model of objects where useful and procedural where practical is the most effective method of coding. It’s a shame we have all these religious wars where people advocate using one method at the expense of the others. They are both good, and they both have their place. Most of the time, there are uses for both methods in every larger project (In some smaller projects, a single object, or a few procedures may be all that you need).

I don’t care for reuse as much as I do for readability. The latter means your code is easier to change. That alone is worth in gold in the craft of building software.

And OO is a pretty damn effective way to make your programs readable. Reuse or no reuse.

“The real world isn’t “OO”,”

Vraiment? My world is full of objects. I’m using one now. I think that having software “objects” model the real objects might not be such a bad thing.

OO designs for conceptual things (like Windows, not real world windows, but the display panels on my computer monitor) often leave a lot to be desired. But for real world things like invoices, shipping orders, insurance claims and what-not, I think those real world things are objects. I have a stack on my desk, so they must be real.

The point of OOP is to give the programmer another means for describing and communicating a solution to a problem in code to machines and people. The most important part of that is the communication to people. OOP allows the programmer to declare what they mean in the code through rules that are enforced in the OO language.

Contrary to many arguments on this topic, OOP and OO concepts are pervasive throughout all code including code in non-OOP languages such as C. Many advanced non-OO programmers will approximate the features of objects even in non-OO languages.

Having OO built into the language merely gives the programmer another means of expression.

The biggest part to writing code is not communication with the machine, that part is easy, the biggest part is communication with human programmers.