La POO est-elle difficile parce que ce n'est pas naturel?

On entend souvent que la POO correspond naturellement à la façon dont les gens perçoivent le monde. Mais je suis tout à fait en désaccord avec cette affirmation: nous (ou du moins je) conceptualisons le monde en termes de relations entre les choses que nous rencontrons, mais l'objectif de la programmation orientée objet est de concevoir des classes individuelles et leurs hiérarchies.

Notez que, dans la vie quotidienne, les relations et les actions existent principalement entre des objets qui auraient été des instances de classes non liées dans la POO. Des exemples de telles relations sont: "mon écran est au-dessus de la table"; "Je (un être humain) est assis sur une chaise"; "une voiture est sur la route"; "Je tape sur le clavier"; "la machine à café fait bouillir de l'eau", "le texte est affiché dans la fenêtre du terminal."

Nous pensons en termes de verbes bivalents (parfois trivalents, comme par exemple dans "je vous ai donné des fleurs") où le verbe est l'action (relation) qui agit sur deux objets pour produire un résultat / action. L' accent est mis sur l'action et les deux (ou trois) objets [grammaticaux] ont la même importance.

Comparez cela à la POO où vous devez d’abord trouver un objet (nom) et lui dire d’exécuter une action sur un autre objet. La façon de penser passe des actions / verbes opérant sur les noms à des noms opérant sur des noms - c'est comme si tout était dit à la voix passive ou réfléchie, par exemple, "le texte est affiché par la fenêtre du terminal". Ou peut-être "le texte se dessine sur la fenêtre du terminal".

Non seulement l'attention est déplacée vers les noms, mais l'un des noms (appelons-le sujet grammatical) a une "importance" supérieure à l'autre (objet grammatical). Ainsi, il faut décider si on va dire terminalWindow.show (someText) ou someText.show (terminalWindow). Mais pourquoi encombrer les gens de décisions aussi triviales sans conséquences opérationnelles alors qu’on entend vraiment montrer (terminalWindow, someText)? [Les conséquences sont insignifiantes sur le plan opérationnel - dans les deux cas, le texte est affiché sur la fenêtre du terminal - mais peuvent être très sérieuses dans la conception des hiérarchies de classes et un "mauvais" choix peut conduire à un code compliqué et difficile à maintenir.]

Je dirais donc que la façon habituelle de faire de la programmation orientée objet (classe unique, envoi unique) est difficile car elle n’EST PAS NATURELLE et ne correspond pas à la façon dont les humains perçoivent le monde. Les méthodes génériques de CLOS sont plus proches de ma façon de penser, mais hélas, cette approche n’est pas généralisée.

Compte tenu de ces problèmes, comment et pourquoi est-il arrivé que la manière traditionnelle de faire de la programmation orientée objet soit devenue si populaire? Et que peut-on faire, le cas échéant, pour le détrôner?

La POO n'est pas naturelle pour certains problèmes. Donc, c'est procédural. Donc, c'est fonctionnel. Je pense que la POO a deux problèmes qui le rendent vraiment difficile.

1. Certaines personnes agissent comme si c'était la seule façon de programmer et que tous les autres paradigmes étaient faux. IMHO tout le monde devrait utiliser un langage multiparadigm et choisir le meilleur paradigme pour le sous-problème sur lequel ils travaillent actuellement. Certaines parties de votre code auront un style OO. Certains seront fonctionnels. Certains auront un style procédural direct. Avec l'expérience, il devient évident quel paradigme convient le mieux à quoi:

   une. OO est généralement préférable lorsque vous avez des comportements fortement liés à l'état sur lequel ils opèrent, et que la nature exacte de l'état est un détail de mise en œuvre, mais son existence ne peut pas être facilement résumée. Exemple: classes de collections.

   b. La procédure est préférable pour les comportements qui ne sont pas fortement couplés à des données particulières. Par exemple, ils fonctionnent peut-être sur des types de données primitifs. Il est plus facile de penser que le comportement et les données sont des entités distinctes ici. Exemple: code numérique.

   c. Fonctionnel est préférable lorsque vous avez quelque chose d'assez facile à écrire de manière déclarative, de telle sorte que l'existence de n'importe quel état est un détail de mise en œuvre qui peut être facilement résumé. Exemple: mapper / réduire le parallélisme.

2. OOP montre généralement son utilité sur les grands projets où il est vraiment nécessaire d'avoir des morceaux de code bien encapsulés. Cela n'arrive pas trop dans les projets pour débutants.

IMHO c'est une question de goût personnel et de façons de penser. Je n'ai pas trop de problème avec OO.

Nous (ou du moins je) conceptualisons le monde en termes de relations entre les choses que nous rencontrons, mais l'objectif de la programmation orientée objet est de concevoir des classes individuelles et leurs hiérarchies.

IMHO ce n'est pas tout à fait, bien que cela puisse être une perception commune. Alan Kay, l'inventeur du terme OO, insistait toujours sur les messages envoyés entre les objets, plutôt que les objets eux - mêmes. Et les messages, du moins pour moi, dénotent des relations.

Notez que, dans la vie quotidienne, les relations et les actions existent principalement entre des objets qui auraient été des instances de classes non liées dans la POO.

S'il existe une relation entre les objets, ils sont liés, par définition. Dans OO, vous pouvez l'exprimer avec une dépendance d'association / agrégation / utilisation entre deux classes.

Nous pensons en termes de verbes bivalents (parfois trivalents, comme dans, par exemple, "je vous ai donné des fleurs") où le verbe est l'action (relation) qui agit sur deux objets pour produire un résultat / une action. L'accent est mis sur l'action et les deux (ou trois) objets [grammaticaux] ont la même importance.

Mais ils ont toujours leurs rôles bien définis dans le contexte: sujet, objet, action, etc. "Je t'ai donné des fleurs" ou "Tu m'as donné des fleurs", ce n'est pas la même chose (sans parler de "Fleur que tu m'as donnée"): -)

Comparez cela à la POO où vous devez d’abord trouver un objet (nom) et lui dire d’exécuter une action sur un autre objet. La façon de penser passe des actions / verbes opérant sur les noms à des noms opérant sur des noms - c'est comme si tout était dit à la voix passive ou réfléchie, par exemple, "le texte est affiché par la fenêtre du terminal". Ou peut-être "le texte se dessine sur la fenêtre du terminal".

Je ne suis pas d'accord avec ça. IMHO la phrase anglaise "Bill, go to hell" se lit plus naturellement dans le code du programme bill.moveTo(hell)plutôt que move(bill, hell). Et le premier est en fait plus analogue à la voix active d'origine.

Ainsi, il faut décider si on va dire terminalWindow.show (someText) ou someText.show (terminalWindow)

Encore une fois, ce n’est pas la même chose de demander au terminal d’afficher du texte ou de demander au texte d’afficher le terminal. À mon humble avis, celui qui est le plus naturel est assez évident.

Compte tenu de ces problèmes, comment et pourquoi est-il arrivé que la manière traditionnelle de faire de la programmation orientée objet soit devenue si populaire?

Peut-être parce que la majorité des développeurs OO voient OO différemment de vous?

Certains programmeurs ont du mal à utiliser OOD car ils aiment réfléchir à la façon de résoudre le problème pour l'ordinateur, et non à la résolution du problème.

... mais l'objectif de la programmation orientée objet est de concevoir des classes individuelles et leurs hiérarchies.

OOD n'est pas à ce sujet. OOD consiste à déterminer comment les choses se comportent et interagissent.

Nous pensons en termes de verbes bivalents (parfois trivalents, comme dans, par exemple, "je vous ai donné des fleurs") où le verbe est l'action (relation) qui agit sur deux objets pour produire un résultat / une action. L'accent est mis sur l'action et les deux (ou trois) objets [grammaticaux] ont la même importance.

L'accent mis sur OOD est toujours sur l'action, où les actions sont les comportements des objets. Les objets ne sont rien sans leurs comportements. La seule contrainte d'objet de OOD est que tout doit être fait par quelque chose.

Je ne pense pas que l'auteur soit plus important que le fait d'avoir fait quelque chose.

Mais pourquoi encombrer les gens de décisions aussi triviales sans conséquences opérationnelles alors qu’on entend vraiment montrer (terminalWindow, someText)?

Pour moi, c'est la même chose avec une notation différente. Vous devez encore décider qui est le show-er et qui est le show-ee. Une fois que vous savez cela, il n'y a pas de décision dans OOD. Windows afficher le texte -> Window.Show (texte).

Beaucoup de choses (surtout dans le domaine des legs) disent que c'est OO quand ça ne l'est pas. Par exemple, il existe une énorme quantité de code C ++ qui ne met pas en œuvre une figure de OOD.

OOD est facile une fois que vous sortez de l'état d'esprit que vous résolvez un problème pour les ordinateurs. Vous résolvez des problèmes pour des choses qui font des choses.

Peut-être que je ne peux pas comprendre le point, mais:

En lisant le premier livre sur la POO (début des années 90, le manuel élancé de Borland à Pascal), j'ai été simplement surpris par sa simplicité et son potentiel. (Avant, j'utilisais le cobol, le fortran, le langage d'assemblage et d'autres éléments préhistoriques.)

Pour moi, c'est assez clair: un chien est un animal, un animal doit manger, mon chien est un chien, il doit donc manger ...

De l'autre côté, la programmation elle-même est intrinsèquement artificielle (c'est-à-dire artificielle). Le langage humain est artificiel (ne me blâmez pas, nous avons tous appris notre langue auprès des autres, personne ne connaît la personne qui a inventé l'anglais). Selon certains scientifiques, l'esprit de l'homme est formé par le langage qu'il a appris en premier.

J'admets que certaines constructions dans les langages OO modernes sont un peu gênantes, mais c'est l'évolution.

Une des choses qui m'a rendu la tâche difficile, c'est de penser que la programmation orientée objet était une modélisation du monde. Je pensais que si je ne l'avais pas bien compris, quelque chose pourrait venir me mordre à la gorge (une chose est vraie ou ne l'est pas). J'étais très conscient des problèmes que prétendre que tout est un objet ou une entité. Cela m'a rendu très hésitant et peu confiant quant à la programmation en POO.

Ensuite, j'ai lu SICP et compris de nouveau qu'il était vraiment question de types de données et de contrôle de leur accès. Tous les problèmes que j’avais fondus parce qu’ils reposaient sur une fausse prémisse, à savoir que vous représentiez le monde sous OOP.

Je m'émerveille toujours de l'immense difficulté que cette fausse prémisse m'avait donnée (et de la façon dont je me suis laissé redevable).

Oui, la programmation orientée objet elle-même est très peu naturelle - le monde réel n'est pas entièrement constitué de taxonomies hiérarchiques. Quelques petites parties de celle-ci sont constituées de ce matériau, et ces parties sont les seules choses qui pourraient être correctement exprimées en termes de OO. Tout le reste ne peut pas être naturellement inséré dans un mode de pensée aussi trivial et limité. Voir les sciences naturelles, voir combien de langages mathématiques différents ont été inventés pour exprimer de la manière la plus simple ou au moins compréhensible la complexité du monde réel. Et presque aucun d'entre eux ne peut être facilement traduit dans un langage d'objets et de messages.

Nous (ou du moins je) conceptualisons le monde en termes de relations entre les choses que nous rencontrons, mais l'objectif de la programmation orientée objet est de concevoir des classes individuelles et leurs hiérarchies.

Vous partez de (IMO) d'une fausse prémisse. Les relations entre les objets sont sans doute plus importantes que les objets eux-mêmes. Ce sont les relations qui donnent une structure de programme orientée objet. L'héritage, la relation entre les classes, est bien sûr important car la classe d'un objet détermine ce que cet objet peut faire. Mais ce sont les relations entre les objets individuels qui déterminent ce que fait réellement un objet dans les limites définies par la classe, et donc le comportement du programme.

Le paradigme orienté objet peut être difficile au début, non pas parce qu'il est difficile d'imaginer de nouvelles catégories d'objets, mais parce qu'il est difficile d'envisager un graphe d'objets et de comprendre quelles devraient être les relations entre eux, en particulier lorsque vous ne possédez pas un objet. façon de décrire ces relations. C'est pourquoi les modèles de conception sont si utiles. Les modèles de conception concernent presque entièrement les relations entre les objets. Les modèles nous fournissent à la fois les éléments de base que nous pouvons utiliser pour concevoir les relations d’objet à un niveau supérieur et un langage que nous pouvons utiliser pour décrire ces relations.

La même chose est vraie dans les domaines créatifs qui fonctionnent dans le monde physique. N'importe qui peut créer un groupe de pièces et appeler cela un bâtiment. Les chambres peuvent même être entièrement meublées avec tous les derniers accoutrements, mais cela ne fait pas le travail de la construction. Le travail d'un architecte consiste à optimiser les relations entre ces salles en fonction des besoins des personnes utilisant ces salles et de l'environnement du bâtiment. La réussite de ces relations est ce qui fait qu'un bâtiment fonctionne à la fois d'un point de vue fonctionnel et esthétique.

Si vous rencontrez des difficultés pour vous habituer à la programmation orientée objet, je vous encourage à réfléchir davantage à la manière dont vos objets s'intègrent et à l'organisation de leurs responsabilités. Si vous ne l'avez pas déjà fait, lisez à propos des modèles de conception - vous vous rendrez probablement compte que vous avez déjà vu les modèles qui vous intéressent, mais leur donner des noms vous permettra de voir non seulement des arbres, mais aussi des peuplements, des bosquets, des bosquets, les bois, les bosquets, les boisés et éventuellement les forêts.

Ceci est seulement une partie de ce qui ne va pas avec la POO.

Essentiellement, les fonctions deviennent des citoyens de seconde classe, ce qui est mauvais.

Les langages modernes (ruby / python) ne souffrent pas de ce problème et fournissent des fonctions en tant qu'objets de première classe, tout en vous permettant de créer des programmes sans créer de hiérarchie de classes.

OOP n'est pas difficile. Ce qui le rend difficile à utiliser, c’est une compréhension superficielle de son utilité, dans laquelle les programmeurs entendent des maximes au hasard et se les répètent à voix basse pour recevoir les bénédictions du divin Gang of Four, du bienheureux Martin Fowler, ou quiconque d'autre qu'ils ont lu.

ÉDITÉ

Tout d’abord, je voudrais dire que je n’ai jamais trouvé la POO difficile, ni plus difficile que d’autres paradigmes de programmation. La programmation est intrinsèquement difficile car elle tente de résoudre des problèmes du monde réel et le monde réel est extrêmement complexe. Par contre, en lisant cette question, je me suis posé la question suivante: la POO est-elle "plus naturelle" que d’autres paradigmes? Et donc plus efficace?

Une fois, j’ai trouvé un article (j’aimerais souhaiter le retrouver afin de pouvoir le poster à titre de référence) sur une étude comparative entre la programmation impérative (IP) et la programmation orientée objet (OOP). Ils avaient essentiellement mesuré la productivité des programmeurs professionnels utilisant IP et OOP dans différents projets, et le résultat était qu'ils n'avaient pas constaté de grandes différences. Ainsi, l’affirmation était qu’il n’y avait pas de grande différence de productivité entre les deux groupes et que ce qui comptait vraiment, c’était l’expérience.

D’autre part, les partisans de l’orientation par objets affirment que, même si, au début du développement d’un système, la POO peut même prendre plus de temps qu’impératif, le code est plus facile à maintenir et à étendre du fait de l’intégration étroite des données entre les utilisateurs. opérations.

J'ai principalement travaillé avec des langages POO (C ++, Java), mais j'ai souvent le sentiment que je pourrais être aussi productif avec Pascal ou Ada, même si je ne les ai jamais essayés pour de grands projets.

Comparez cela à la POO où vous devez d’abord trouver un objet (nom) et lui dire d’exécuter une action sur un autre objet.

[Couper]

Je dirais donc que la façon habituelle de faire de la programmation orientée objet (classe unique, envoi unique) est difficile car elle n’EST PAS NATURELLE et ne correspond pas à la façon dont les humains perçoivent le monde. Les méthodes génériques de CLOS sont plus proches de ma façon de penser, mais hélas, cette approche n’est pas généralisée.

Lorsque j'ai lu ce dernier paragraphe plus attentivement, j'ai enfin compris le point essentiel de votre question et j'ai dû réécrire ma réponse à partir de zéro. :-)

Je connais d’autres propositions d’OA dans lesquelles plusieurs objets reçoivent un message au lieu d’un seul, c’est-à-dire que plusieurs objets jouent un rôle symétrique lors de la réception d’un message. OUI, cela me semble une approche plus générale et peut-être plus naturelle (moins restrictive).

D'autre part, "l'envoi multiple" peut être facilement simulé en utilisant "l'envoi unique" et "l'envoi unique" est plus facile à mettre en œuvre. C’est peut-être une des raisons pour lesquelles la "répartition multiple" n’est pas devenue une pratique courante.

Arrêtez de rechercher un paradigme exclusivement POO et essayez du JavaScript.

Je suis actuellement en train de définir un schéma dans lequel mes objets d'interface utilisateur fonctionnent dans une interface pilotée par les événements. C'est-à-dire que j'aurai ce qui ressemble à une méthode publique typique qui, lorsqu'elle est renvoyée, donne lieu à une action définie en interne. Mais quand il est déclenché, ce qui se passe réellement, c'est que je déclenche un événement sur l'objet lui-même et qu'un gestionnaire prédéfini à l'intérieur de cet objet répond. Cet événement et l'objet d'événement auquel vous pouvez associer des propriétés qui sont transmises à tout autre auditeur peuvent être entendus par tout ce qui est attentif à l'écoute. Vous pouvez écouter directement l'objet, ou vous pouvez généralement écouter ce type d'événement (les événements sont également déclenchés sur un objet générique que tous les objets construits par la fabrique peuvent écouter). Ainsi, par exemple, j'ai une liste déroulante dans laquelle vous sélectionnez un nouvel élément dans la liste déroulante.

Si vous le souhaitez (et j'ai été surpris de découvrir que ce n'est généralement pas le cas - c'est un problème de lisibilité lorsque vous ne pouvez pas voir d'où provient l'événement), vous pouvez effectuer un découplage complet de l'objet et établir un contexte via un objet événement transmis. Quoi qu'il en soit, vous évitez toujours les envois uniques en pouvant enregistrer plusieurs intervenants.

Mais je ne fais pas cela avec OOP uniquement et JS n’est même pas «correctement» OOP selon certaines définitions, ce que je trouve hilarant. À mon avis, le niveau de développement d’applications supérieur est correct, c’est le pouvoir de modifier le paradigme en fonction de ce qui convient à votre situation et nous pouvons imiter les classes à la perfection si nous le souhaitons. Mais dans ce cas, je mélange des aspects fonctionnels (transfert des gestionnaires) avec la POO.

Plus important encore, ce que j'ai se sent assez puissant. Je ne pense pas en termes d'objet agissant sur un autre. En gros, je décide de ce qui importe aux objets, en leur donnant les outils dont ils ont besoin pour régler les problèmes, en les glissant simplement dans un mélangeur et en les laissant réagir les uns par rapport aux autres.

Je suppose donc que ce que je dis est le suivant: ce n’est pas un problème de déclaration de substitution. C'est mélanger et assortir. Le problème, ce sont les langages et les modes qui veulent que vous croyiez que c’est une chose qui est trop chère. Comment un développeur java junior, par exemple, peut-il vraiment apprécier la programmation orientée objet alors qu’il pense qu’il le fait toujours correctement par défaut?

On m'a expliqué que c'était avec un grille-pain et une voiture. Les deux ont des ressorts, donc vous auriez un objet "ressort" et ils seraient de tailles, de forces différentes et peu importe, mais ils seraient tous deux des "ressorts" et étendreaient ensuite cette métaphore sur la voiture, si vous aviez beaucoup de roues (Roues, évidemment, plus le volant, etc.) et cela avait beaucoup de sens.

Vous pouvez alors voir le programme comme une liste d'objets, et il est beaucoup plus simple de visualiser "C'est une liste de choses qui font des choses, donc ce n'est pas comme cette liste d'instructions que vous avez vues auparavant"

Je pense que le vrai problème avec la POO est la façon dont cela est expliqué aux gens. Souvent (dans mes cours d'université), je vois cela s'expliquer en disant "il s'agit de beaucoup de classes qui font de petites choses, et vous pouvez créer des objets à partir de cela" et cela déroute beaucoup de gens, parce qu'il utilise ce qui est essentiellement abstrait termes pour expliquer ces concepts, plutôt que des idées concrètes que les gens ont saisies quand ils avaient 5 ans et qui jouaient avec le lego.

C'est la façon naturelle de penser le monde à travers la catégorisation. C'est plus ou moins ce que OO est à propos. La POO est difficile parce que la programmation est difficile.

Je pense qu'une partie de la difficulté survient lorsque les gens essaient d'utiliser la POO pour représenter la réalité. Tout le monde sait qu'une voiture a quatre roues et un moteur. Tout le monde sait que les voitures peuvent Start(), Move()et SoundHorn().

Une lumière claqua dans ma tête lorsque je compris que je devais arrêter d'essayer de le faire tout le temps. Un objet n'est pas la chose avec laquelle il partage un nom. Un objet est (doit être) une partition de données suffisamment détaillée et pertinente pour l’ampleur du problème. C’est oughtexactement ce dont la solution au problème a besoin, ni plus ni moins. Si rendre un objet responsable d'un comportement entraîne plus de lignes de code que le même comportement étant le travail d'un tiers nébuleux (certains pourraient l'appeler un «poltergeist»), alors le poltergeist gagne ses jetons.

Afin de gérer la complexité, nous devons regrouper les fonctionnalités dans des modules, ce qui est un problème difficile en général. C'est comme le vieil adage du capitalisme, OOP est le pire système pour organiser des logiciels, à l'exception de tout ce que nous avons essayé.

La raison pour laquelle nous groupons les interactions au sein des noms, même s’il existe souvent une ambiguïté quant au nom du groupe avec lequel le grouper, est due au fait que la quantité de noms se trouve dans des classes de taille gérable, alors que le regroupement par verbes a tendance à produire de très petits groupes comme des ponctuels ou de très grands groupes pour une fonction comme un spectacle . Les concepts de réutilisation tels que l'héritage s'avèrent également beaucoup plus faciles lors du regroupement par noms.

De plus, la question de décider de mettre en évidence la fenêtre ou le texte est presque toujours beaucoup plus claire en pratique qu'en théorie. Par exemple, presque tous les groupes de kits d’outils graphiques s’ajoutent au conteneur mais s’affichent avec le widget. Si vous essayez d'écrire du code dans l'autre sens, la raison apparaît assez rapidement, même si vous y réfléchissez de manière abstraite, les deux méthodes semblent interchangeables.

Non . Il existe plusieurs façons de résoudre un problème à l'aide de la programmation: fonctionnelle, procédurale, logique, POO, autre.

Dans le monde réel, les gens utilisent parfois le paradigme fonctionnel, parfois le paradigme procédural, etc. Et parfois nous nous sommes mélangés. Et finalement, nous les représentons comme un style ou un paradigme particulier de programmation.

Il existe également le paradigme "tout est une liste ou un élément", utilisé dans LISP. J'aime parler d'une chose différente de la programmation fonctionnelle . PHP utilise cela dans les tableaux associatifs.

Les paradigmes OOP et "Tout est une liste ou un élément" sont considérés comme deux des styles de programmation PLUS NATURELS , comme je me souviens dans certaines classes d'Intelligence Artificielle.

Cela me semble bizarre, "La POO n'est pas naturelle", peut-être que la façon dont vous apprenez, ou la façon dont vous avez été enseigné sur la POO est fausse, mais pas la POO elle-même.

Compte tenu de ces problèmes, comment et pourquoi est-il arrivé que la manière traditionnelle de faire de la programmation orientée objet soit devenue si populaire? Et que peut-on faire, le cas échéant, pour le détrôner?

OOP est devenu populaire car il offre des outils pour organiser votre programme à un niveau d'abstraction plus élevé que les langages procéduraux populaires qui l'ont précédé. Il était également relativement facile de créer un langage comportant une structure procédurale à l'intérieur des méthodes et une structure orientée objet les entourant. Cela a permis aux programmeurs qui savaient déjà comment programmer de manière procédurale de saisir les principes OO un à la fois. Cela a également conduit à beaucoup de programmes OO-in-name-only qui étaient des programmes procéduraux encapsulés dans une classe ou deux.

Pour détrôner OO, construisez un langage qui facilite la transition progressive de ce que la plupart des programmeurs savent aujourd'hui (essentiellement procédural, avec un peu d'OO) vers votre paradigme préféré. Assurez-vous qu'il fournit des API pratiques pour effectuer les tâches courantes et bien le promouvoir. Les gens vont bientôt créer des programmes X-in-name-only dans votre langue. Ensuite, vous pouvez vous attendre à ce que cela prenne des années et des années pour que les gens s’exercent réellement à la pratique de X.

Je pense que les langues OOP et OOP ont aussi des problèmes.

Si vous le comprenez bien, la POO concerne les boîtes noires (objets) sur lesquelles se trouvent des boutons qui peuvent être enfoncés (méthodes). Les classes ne sont là que pour aider à organiser ces boîtes noires.

L'un des problèmes est que le programmeur place les boutons sur le mauvais objet. Le terminal ne peut pas afficher le texte sur lui-même, le texte ne peut pas s'afficher sur le terminal. Le composant du gestionnaire de fenêtres du système d'exploitation qui peut le faire. La fenêtre de terminal et le texte sont juste une entité passive. Mais si nous pensons ainsi, nous réalisons que la plupart des entités sont des choses passives et que nous n’aurions que très peu d’objets capables de faire quoi que ce soit (ou tout simplement un: l’ordinateur ). En effet, lorsque vous utilisez C, vous l’organisez en modules, ceux-ci ne représentent que quelques objets.

Un autre point est que l'ordinateur exécute simplement les instructions de manière séquentielle. Supposons que vous avez un VCRet un Televisionobjet, comment joueriez-vous la vidéo? Vous écrivez probablement quelque chose comme ceci:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

Ce serait aussi simple que cela, mais il vous faudrait au moins 3 processeurs ( ou processus ) pour cela: l'un joue votre rôle, le second est le magnétoscope, le troisième est le téléviseur. Mais normalement, vous n’avez qu’un seul noyau (du moins pas assez pour tous vos objets). À l'université, bon nombre de mes camarades ne comprenaient pas pourquoi l'interface graphique se fige lorsqu'un bouton-poussoir effectue une opération coûteuse.

Donc, je pense qu'un design orienté objet peut très bien décrire le monde, mais ce n'est pas la meilleure abstraction pour ordinateur.

Jetez un coup d'œil à la DCI (données, contexte et interaction) inventée par l'inventeur du modèle MVC.

Le but de DCI est (cité dans Wikipedia):

• Donne au comportement du système un statut de première classe, au-dessus des objets (noms).
• Séparer proprement le code pour que le comportement du système change rapidement (ce que fait le système) du code pour modifier lentement la connaissance du domaine (ce qu'est le système), au lieu de combiner les deux dans une interface de classe.
• Soutenir un style de pensée objet qui est proche des modèles mentaux des gens, plutôt que le style de pensée de classe.

Voici un bon article écrit par les auteurs et voici un petit exemple d'implémentation (.NET) si vous voulez voir du code. C'est beaucoup plus simple que cela puisse paraître et cela semble très naturel.

On entend souvent que la POO correspond naturellement à la façon dont les gens perçoivent le monde. Mais je suis fortement en désaccord avec cette affirmation (...)

Comme il est évangélisé dans les livres et ailleurs pendant des décennies, je ne suis pas d'accord avec cela aussi. Néanmoins, je pense que ce sont Nygaard et Dahl qui ont formulé cette idée, et ils se sont concentrés sur le fait qu'il était plus facile de concevoir des simulations par rapport aux solutions de rechange de l'époque.

(...) mais l'objectif de la programmation orientée objet est de concevoir des classes individuelles et leurs hiérarchies.

Cette affirmation entre dans un territoire sensible compte tenu de la popularité répandue des idées fausses sur la programmation orientée objet et de la sensibilité à la définition de OO J'ai plus de dix ans dans le domaine, travaillant à la fois dans l'industrie et dans la recherche universitaire sur les prog. langues, et je peux vous dire que j'ai passé de nombreuses années à désapprendre le "grand public", car j'ai commencé à remarquer à quel point il était différent (et inférieur) de ce que les premiers créateurs visaient. Pour un traitement moderne et actualisé du sujet, je me référerai aux récents efforts de W. Cook:

"Proposition de définitions modernes et simplifiées des termes" objet "et" objet ", http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Compte tenu de ces problèmes, comment et pourquoi est-il arrivé que la manière traditionnelle de faire de la programmation orientée objet soit devenue si populaire?

Peut-être la même raison pour laquelle les claviers QWERTY sont devenus populaires ou la même raison pour laquelle le système d'exploitation DOS est devenu populaire. Les choses se passent simplement avec des véhicules populaires, malgré leurs propriétés, et deviennent populaires eux-mêmes. Et parfois, des versions similaires mais pires de quelque chose sont considérées comme la chose réelle.

Et que peut-on faire, le cas échéant, pour le détrôner?

Ecrivez un programme en utilisant une approche supérieure. Écrivez le même programme en utilisant une approche orientée objet. Montrer que le premier a de meilleures propriétés que le dernier dans tous les aspects significatifs (propriétés du système lui-même et propriétés techniques). Montrez que le programme choisi est pertinent et que l'approche proposée préserve la haute qualité des propriétés si elle est appliquée à d'autres types de programmes. Soyez rigoureux dans votre analyse et utilisez des définitions précises et acceptées lorsque cela est nécessaire.

Enfin, partagez vos découvertes avec nous.

Prenons Java: les objets sont une sorte de goulet d’étranglement d’abstraction. La plupart des «choses» sont soit strictement des sous-composants d’objets, soit utilisent des objets comme sous-composants. Les objets doivent être suffisamment polyvalents pour constituer une couche d'abstraction complète entre ces deux types de choses - cela signifie qu'il n'y a pas de métaphore unique dans laquelle ils incarnent. En particulier, Java fait des objets (& classes) la seule couche par laquelle vous appelez / envoyez le code. Cette quantité de choses que les objets incarnent les rend franchement beaucoup trop complexes. Toute description utile de celles-ci doit être limitée à une forme spécialisée ou restreinte.

Les hiérarchies d'héritage et d'interface sont des "choses" qui utilisent des objets comme sous-composants. C'est une manière spécialisée de décrire des objets, pas une façon de tirer une compréhension générale des objets.

On peut dire que les "objets" ont ou ont beaucoup de choses, car ils constituent une abstraction à usages multiples plus ou moins universelle dans un "langage à l'origine". S'ils sont utilisés pour contenir un état mutable local ou pour accéder à un état mondial externe, ils ressemblent beaucoup à un "nom".

En revanche, un objet qui représente un processus, par exemple "chiffrer", "compresser" ou "trier", ressemble à un "verbe".

Certains objets sont utilisés pour leur rôle d'espaces de noms, par exemple un emplacement pour placer une fonction "statique" en Java.

Je suis enclin à souscrire à l'argument selon lequel Java est trop lourd en appels de méthodes d'objet, avec une répartition sur l'objet. C'est probablement parce que je préfère les classes de types de Haskell pour contrôler la répartition. Ceci est une limitation de la distribution et est une fonctionnalité de Java mais pas la plupart des langues, ni même la plupart des langages OO.

J'ai assisté et participé à de nombreux débats en ligne sur la POO. Les partisans de la programmation orientée objet ne savent généralement pas comment écrire le code de procédure approprié. Il est possible d’écrire un code de procédure hautement modulaire. Il est possible de séparer le code et les données et de s'assurer que les fonctions ne peuvent écrire que dans leur propre magasin de données. Il est possible de mettre en œuvre le concept d'héritage à l'aide d'un code de procédure. Plus important encore, le code de procédure est plus fin, plus rapide et plus facile à déboguer.

Si vous construisez des modules à fichier unique avec des conventions de dénomination strictes, le code de procédure est plus facile à écrire et à gérer que OO et il en fera de même ou plus et plus rapidement. Et n'oubliez pas que lorsque votre application est exécutée, elle est toujours procédurale, quel que soit le nombre de classes présentes dans votre script.

Vous avez ensuite le problème des langages tels que PHP, qui ne sont pas vraiment orientés objet et reposent sur des hacks pour simuler des éléments tels que l’héritage multiple. Les gros lanceurs qui influencent la direction du langage ont transformé PHP en un patchwork de règles incohérentes devenues trop volumineuses pour l’objectif initial. Quand je vois des développeurs écrire d’énormes classes de templates pour ce qui était conçu comme un langage de template procédural, je ne peux pas m'empêcher de sourire.

Si vous comparez un code OO correctement écrit avec un code procédural mal écrit, vous aboutirez toujours à une conclusion erronée. Très peu de projets justifient une conception orientée objet. Si vous êtes IBM et gérez un énorme projet qui doit être maintenu pendant des années par plusieurs développeurs, optez pour Object Oriented. Si vous écrivez un petit blog ou un site Web de shopping pour un client, réfléchissez-y à deux fois.

Pour répondre à la question initiale, la programmation orientée objet est difficile car elle ne résout pas les dilemmes de la programmation dans la vie réelle sans recourir à des solutions 100 fois plus complexes qu'elles ne devraient l'être. L'utilisation judicieuse de données globales est l'une des solutions les plus puissantes à de nombreux problèmes de programmation. Pourtant, les diplômés universitaires de la nouvelle vague vous diront que c'est un gros non-non. Les données disponibles dans le monde entier sont dangereuses uniquement si vous êtes un lapin de programmation maladroit. Si vous avez mis en place un ensemble de règles strictes et des conventions de dénomination appropriées, vous pouvez vous passer de la globalisation de toutes vos données.

Il devrait être obligatoire pour tout programmeur orienté objet de savoir écrire une application de jeu d'échecs en assembleur pour une mémoire disponible maximale de 16K. Ils apprendraient ensuite à couper la graisse, à réduire la paresse et à trouver des solutions ingénieuses.