OOP difficile parce que ce n'est pas naturel?
On peut souvent entendre que OOP correspond naturellement à la façon dont les gens pensent du monde. Mais je suis fortement en désaccord avec cette affirmation: nous (ou du moins je) conceptualise le monde en termes de - relations entre les choses que nous rencontrons, mais l'objectif de OOP 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 en haut de la table"; "Je (un être humain) suis 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 opère sur deux objets pour produire un résultat/action. Le focus est sur l'action, et les deux (ou trois) objets [grammaticaux] ont une importance égale.
Comparez cela avec OOP où vous devez d'abord trouver un objet (nom) et lui dire d'effectuer une action sur un autre objet. La façon de penser passe des actions/verbes opérant sur les noms aux noms opérant sur des noms - c'est comme si tout était dit d'une voix passive ou réflexive, 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 le focus est déplacé sur les noms, mais l'un des noms (appelons-le sujet grammatical) reçoit une "importance" plus élevée que l'autre (objet grammatical). Ainsi, il faut décider si l'on dira terminalWindow.show (someText) ou someText.show (terminalWindow). Mais pourquoi alourdir les gens avec de telles décisions triviales sans conséquences opérationnelles quand on veut vraiment dire (terminalWindow, someText)? [Les conséquences sont sur le plan opérationnel insignifiantes - dans les deux cas, le texte est affiché sur la fenêtre du terminal - mais peut être très grave dans la conception des hiérarchies de classes et un "mauvais" choix peut conduire à des situations compliquées et difficiles pour maintenir le code.]
Je dirais donc que la manière traditionnelle de faire OOP (basée sur une classe, envoi unique) est difficile car elle IS NON NATURELLE et ne correspond pas à la façon dont les humains pensent au 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 répandue.
Compte tenu de ces problèmes, comment/pourquoi est-il arrivé que la façon de faire actuellement courante OOP soit devenue si populaire? Et que peut-on faire, le cas échéant, pour la détrôner?
La POO n'est pas naturelle pour certains problèmes. C'est donc procédural. Donc, c'est fonctionnel. Je pense que OOP a deux problèmes qui le rendent vraiment difficile.
Certaines personnes agissent comme si c'était la seule vraie façon de programmer et tous les autres paradigmes sont faux. À mon humble avis, tout le monde devrait utiliser un langage multiparadigme et choisir le meilleur paradigme pour le sous-problème sur lequel il travaille actuellement. Certaines parties de votre code auront un style OO. Certaines seront fonctionnelles. Certaines auront un style procédural simple. Avec l'expérience, il devient évident quel paradigme est le mieux pour quoi:
une. OO est généralement préférable lorsque vous avez des comportements fortement couplés à l'état sur lequel ils opèrent, et la nature exacte de l'état est un détail d'implémentation, mais son existence ne peut pas être facilement abstraite Exemple: classes de collections.
b. La procédure est préférable lorsque vous avez un tas de comportements qui ne sont pas fortement associés à des données particulières. Par exemple, ils fonctionnent peut-être sur des types de données primitifs. Il est plus facile de considérer le comportement et les données comme des entités distinctes ici. Exemple: code numérique.
c. La fonctionnalité est meilleure lorsque vous avez quelque chose d'assez facile à écrire de manière déclarative, de sorte que l'existence de n'importe quel état est un détail d'implémentation qui peut être facilement résumé. Exemple: mapper/réduire le parallélisme.
La POO 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 ne se produit pas trop dans les projets débutants.
À mon humble avis, c'est une question de goût personnel et de modes de pensée. Je n'ai pas beaucoup de problème avec OO.
Nous (ou du moins je) conceptualise le monde en termes de relations entre les choses que nous rencontrons, mais l'objectif de OOP est de concevoir des classes individuelles et leurs hiérarchies.
À mon humble avis, ce n'est pas tout à fait le cas, même si cela peut être une perception courante. Alan Kay, l'inventeur du terme OO, a toujours souligné les messages envoyés entre les objets, plutôt que les objets eux-mêmes. Et les messages, au 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. En OO vous pouvez l'exprimer avec une dépendance d'association/d'agrégation/d'utilisation entre deux classes.
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 opère sur deux objets pour produire un résultat/action. L'accent est mis sur l'action et les deux (ou trois) objets [grammaticaux] ont une importance égale.
Mais ils ont toujours leurs rôles bien définis dans le contexte: sujet, objet, action, etc. -)
Comparez cela avec OOP où vous devez d'abord trouver un objet (nom) et lui dire d'effectuer une action sur un autre objet. La façon de penser passe des actions/verbes opérant sur les noms aux noms opérant sur des noms - c'est comme si tout était dit d'une voix passive ou réflexive, 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 suis en désaccord avec cela. À mon humble avis, la phrase anglaise "Bill, go to hell" se lit plus naturellement dans le code du programme sous la forme 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 l'on dira 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, il est assez évident lequel est le plus naturel.
Compte tenu de ces problèmes, comment/pourquoi est-il arrivé que la façon de faire actuellement courante OOP soit devenue si populaire?
Peut-être parce que la majorité des développeurs OO voient différemment OO) que vous?
Certains programmeurs trouvent OOD difficile parce que ces programmeurs aiment réfléchir à la façon de résoudre le problème pour l'ordinateur, pas à la façon dont le problème devrait être résolu.
... mais l'objectif de OOP est de concevoir des classes individuelles et leurs hiérarchies.
OOD n'est pas à ce sujet. OOD consiste à comprendre comment les choses se comportent et interagissent.
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 opère sur deux objets pour produire un résultat/action. L'accent est mis sur l'action et les deux (ou trois) objets [grammaticaux] ont une importance égale.
L'accent 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 d'OOD est que tout doit être fait par quelque chose.
Je ne vois pas le faiseur comme plus important que la chose ayant quelque chose à faire.
Mais pourquoi alourdir les gens avec de telles décisions triviales sans conséquences opérationnelles quand on veut vraiment dire (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, alors il n'y a pas de décision dans OOD. Windows affiche le texte -> Window.Show (texte).
Beaucoup de choses là-bas (en particulier dans la zone héritée) disent que c'est OO quand ce n'est pas le cas. Par exemple, il y a une énorme quantité de code C++ qui n'implémente pas une figue d'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.
Je ne suis peut-être pas en mesure de comprendre le point, mais:
En lisant le premier livre sur OOP (début des années 90, le mince manuel de Borland à Pascal), j'ai simplement été étonné de sa simplicité et de son potentiel (auparavant, j'utilisais Cobol, Fortran, le langage d'assemblage et d'autres trucs préhistoriques.)
Pour moi, c'est assez clair: un chien est un animal, un animal doit manger, mon chien est un chien, donc il doit manger ...
D'un autre côté, la programmation elle-même est intrinsèquement contre nature (c'est-à-dire artificielle). La parole humaine est artificielle (ne me blâmez pas, nous avons tous appris nos langues des autres, personne ne connaît la personne qui a inventé l'anglais), aussi. Selon certains scientifiques, l'esprit humain est formé par la langue qu'il a apprise en premier.
J'admets que certaines constructions dans les langages OO modernes sont un peu maladroites, mais c'est l'évolution.
Une chose qui a rendu les choses difficiles pour moi était de penser que OOP était sur la modélisation du monde. Je pensais que si je ne comprenais pas bien, quelque chose pourrait venir me mordre dans le cul (un chose est vraie ou non) .J'ai été très conscient des problèmes que de faire comme si tout était un objet ou une entité.
Ensuite, j'ai lu SICP et j'ai compris que c'était vraiment une question de types de données et de contrôle d'accès à ces derniers. Tous les problèmes que j'avais dissipés parce qu'ils étaient basés sur une fausse prémisse, qu'en OOP vous modélisez le monde.
Je m'émerveille toujours de l'immense difficulté que cette fausse prémisse m'a donné (et comment je me suis laissé redevable).
Nous (ou du moins je) conceptualise le monde en termes de relations entre les choses que nous rencontrons, mais l'objectif de OOP est de concevoir des classes individuelles et leurs hiérarchies.
Vous partez de (IMO) 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 qu'un objet en fait dans les limites définies par la classe, et donc comment le programme se comporte.
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'imaginer un graphique d'objets et de comprendre quelles devraient être les relations entre eux, en particulier lorsque vous n'avez pas de 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 blocs de construction que nous pouvons utiliser pour concevoir des relations d'objet à un niveau supérieur et un langage que nous pouvons utiliser pour décrire ces relations.
Il en va de même dans les domaines créatifs qui fonctionnent dans le monde physique. N'importe qui pouvait rassembler un tas de pièces et appeler cela un bâtiment. Les chambres peuvent même être entièrement meublées avec les derniers équipements, mais cela ne fait pas fonctionner le bâtiment. Le travail d'un architecte est d'optimiser les relations entre ces pièces en respectant les exigences des personnes utilisant ces pièces et l'environnement du bâtiment. Obtenir ces bonnes relations est ce qui fait qu'un bâtiment fonctionne à la fois d'un point de vue fonctionnel et esthétique.
Si vous avez du mal à vous habituer à la POO, je vous encourage à réfléchir davantage à la façon dont vos objets s'emboîtent et à la façon dont leurs responsabilités sont organisées. Si vous ne l'avez pas déjà fait, lisez les modèles de conception - vous vous rendrez probablement compte que vous avez déjà vu les modèles que vous lisez, mais leur donner des noms vous permettra non seulement de voir des arbres, mais aussi des peuplements, des bosquets, des fourrés, bois, bosquets, boisés et éventuellement forêts.
Oui, OOP lui-même est très peu naturel - le monde réel n'est pas entièrement fait de taxonomies hiérarchiques. Quelques petites parties de celui-ci sont faites de ce genre de choses, et ces parties sont les seules choses qui pourraient être adéquatement exprimée en termes d'OO. Tout le reste ne peut pas naturellement s'intégrer dans une façon de penser aussi triviale et limitée. Voir les sciences naturelles, voir combien de langages mathématiques différents ont été inventés afin d'exprimer de la manière la plus simple ou du moins compréhensible façon 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.
MODIFIÉ
Tout d'abord, je voudrais dire que je n'ai jamais trouvé OOP difficile, ou plus difficile que d'autres paradigmes de programmation. La programmation est intrinsèquement difficile parce qu'elle essaie de résoudre des problèmes du monde réel et du monde réel est Par contre, en lisant cette question, je me suis demandé: OOP "plus naturel" que les autres paradigmes? Et donc plus efficace?
J'ai trouvé un article (j'aimerais pouvoir le retrouver pour pouvoir le poster comme référence) sur une étude comparative entre la programmation impérative (IP) et la programmation orientée objet (POO). 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 vu de grandes différences. Donc, l'affirmation était qu'il n'y avait pas de grande différence dans productivité entre les deux groupes, et que ce qui compte vraiment, c'est l'expérience.
D'un autre côté, les partisans de l'orientation objet affirment que, alors que pendant le développement précoce d'un système OOP peut même prendre plus de temps que impératif, à long terme, le code est plus facile à maintenir et à étendre en raison de l'intégration étroite entre les données et les opérations.
J'ai principalement travaillé avec OOP langages (C++, Java) mais j'ai souvent le sentiment que je pourrais être aussi productif en utilisant Pascal ou Ada même si je ne les ai jamais essayés pour de grands projets.
Comparez cela avec OOP où vous devez d'abord trouver un objet (nom) et lui dire d'effectuer une action sur un autre objet.
[couper]
Je dirais donc que la manière traditionnelle de faire OOP (basée sur une classe, envoi unique) est difficile car elle IS NON NATURELLE et ne correspond pas à la façon dont les humains pensent au 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 répandue.
Lorsque j'ai lu ce dernier paragraphe plus attentivement, j'ai finalement compris le point principal de votre question et j'ai dû réécrire ma réponse à partir de zéro. :-)
Je connais d'autres OO propositions où 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 semble plus général et peut-être plus naturel ( moins restrictif) OOP approche pour moi.
D'un autre côté, la "répartition multiple" peut être facilement simulée à l'aide de la "répartition unique" et la "répartition unique" est plus facile à mettre en œuvre. C'est peut-être une des raisons pour lesquelles "l'envoi multiple" n'est pas devenu courant.
La POO n'est pas difficile. Ce qui rend difficile une bonne utilisation est une compréhension superficielle de ce à quoi cela sert, où les programmeurs entendent des maximes aléatoires et se les répètent à voix basse afin de recevoir les bénédictions du divin Gang of Four, le bienheureux Martin Fowler, ou qui qu'ils lisent d'autre.
Ce n'est qu'une partie de ce qui ne va pas avec la POO.
Essentiellement, les fonctions deviennent des citoyens de seconde zone, 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 construire de hiérarchie de classes.
Arrêtez de chercher un paradigme exclusif OOP et essayez du JavaScript.
J'ai actuellement quelque chose d'un schéma élaboré où mes objets d'interface utilisateur fonctionnent sous une interface événementielle. C'est-à-dire que j'aurai ce qui ressemble à une méthode publique typique qui, lorsqu'elle est déclenchée, entraîne une action définie en interne. Mais quand il est déclenché, ce qui se passe vraiment, 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 événement auquel vous pouvez attacher des propriétés qui sont transmises à tout autre écouteur peuvent être entendus par tout ce qui se soucie d'écouter. Vous pouvez écouter directement l'objet ou écouter généralement 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 l'usine peuvent écouter). Alors maintenant, par exemple, j'ai une zone de liste déroulante dans laquelle vous sélectionnez un nouvel élément dans la liste déroulante. La comboBox sait quoi faire pour définir sa propre valeur d'affichage et mettre à jour le serveur si nécessaire, mais je peux également avoir autant d'autres zones de liste déroulante que je veux écouter pour échanger leurs listes de sélection qui sont liées à la valeur actuelle de la première zone de liste déroulante.
Si vous le souhaitez (et j'ai été surpris de découvrir que je ne le veux généralement pas - c'est un problème de lisibilité lorsque vous ne pouvez pas voir d'où vient l'événement), vous pouvez avoir un découplage complet des objets et établir un contexte via un objet d'événement passé. Quoi qu'il en soit, vous évitez toujours l'envoi unique en étant en mesure d'enregistrer plusieurs intervenants.
Mais je ne fais pas cela avec OOP seul et JS n'est même pas "correctement" OOP selon certaines définitions, que je trouve hilarant. Propre, pour le des niveaux plus élevés de développement d'applications, à mon avis, ont le pouvoir de plier le paradigme à tout ce qui fonctionne pour votre situation et nous pouvons très bien émuler les classes si nous le voulons. Mais dans ce cas, je mélange des aspects fonctionnels (gestionnaires de passage autour) avec OOP.
Plus important encore, ce que j'ai semble assez puissant. Je ne pense pas en termes d'un objet agissant sur un autre. Je décide essentiellement de ce qui compte pour les objets, je leur donne les outils dont ils ont besoin pour trier les choses, je les laisse tomber dans un mélangeur et je les laisse réagir les uns avec les autres.
Je suppose donc que ce que je dis est le suivant: ce n'est pas une sorte de problème de déclaration de commutateur. C'est du mix and match. Le problème, ce sont les langues et les modes qui veulent vous faire croire que c'est une chose uber alles. Comment un junior Java dev, par exemple, peut-il vraiment apprécier OOP quand il pense qu'il le fait toujours correctement par défaut?)
Je pense qu'une partie de la difficulté survient lorsque les gens essaient d'utiliser OOP 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 a cliqué dans ma tête quand j'ai réalisé que je devais arrêter d'essayer de faire ça tout le temps. Un objet n'est pas la chose avec laquelle il partage un nom. Un objet est (c'est-à-dire devrait être) une partition de données suffisamment détaillée et pertinente pour l'étendue du problème. Il ought pour avoir exactement ce que la solution au problème doit avoir, ni plus ni moins. Si le fait de rendre un objet responsable de certains comportements 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.
La façon dont cela m'a été expliqué était avec un grille-pain et une voiture. Les deux ont des ressorts, donc vous auriez un objet "ressort" et ils seraient de différentes tailles, forces et autres, mais ils seraient tous les deux "ressorts" et étendre 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 considérer le programme comme une liste d'objets, et il est beaucoup plus simple de visualiser alors "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 OOP est de savoir comment il est expliqué aux gens. Souvent (dans mes classes uni) je le vois expliqué en disant "il s'agit de beaucoup de classes qui font de petites choses, et vous peut créer des objets à partir de cela "et tout cela déroute beaucoup de gens, car il utilise des termes essentiellement abstraits pour expliquer ces concepts, plutôt que des idées concrètes que les gens ont saisies quand ils avaient 5 ans en jouant 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 sur le point. OOP est difficile parce que la programmation est difficile.
Non. Il existe plusieurs façons de résoudre un problème en utilisant la programmation: fonctionnelle, procédurale, logique, O.O.P., autre.
Dans le monde réel, parfois, les gens utilisent le paradigme fonctionnel, et parfois, nous utilisons le paradigme procédural, etc. Et parfois, nous nous mélangions. Et finalement, nous les représentons comme un style ou un paradigme particulier de programmation.
Il y a aussi le paradigme "tout est une liste ou un élément", utilisé dans LISP. J'aime mentionner autre chose que la programmation fonctionnelle. PHP l'utilise dans les tableaux associatifs.
O.O.P. et les paradigmes "Tout est une liste ou un élément" sont considérés comme 2 des styles de programmation PLUS NATURELS, comme je m'en souviens dans certaines classes d'intelligence artificielle.
Cela me semble bizarre, "O.O.P. n'est pas naturel", peut-être la façon dont vous apprenez, ou la façon dont vous avez appris O.O.P. est faux, mais pas O.O.P. lui-même.
Je pense que les langues OOP et OOP) ont aussi des problèmes.
Si vous comprenez bien, OOP concerne les boîtes noires (objets) qui ont des boutons poussoirs sur lesquels vous pouvez pousser (méthodes). Les classes sont juste là pour aider à organiser ces boîtes noires.
n problème est lorsque le programmeur place les boutons-poussoirs 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 gestionnaire de fenêtres du système d'exploitation qui peut le faire. La fenêtre et le texte du terminal ne sont qu'une entité passive. Mais si nous pensons de cette façon, nous réalisons que la plupart des entités sont des choses passives et nous n'aurons que très peu d'objets qui font réellement quelque chose (ou simplement un: l'ordinateur). En effet lorsque vous utilisez C vous l'organisez en modules, ces modules représentent peu d'objets.
Un autre point est que l'ordinateur exécute simplement les instructions de manière séquentielle. Supposons que vous ayez un objet VCR et Television, comment voulez-vous lire 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 vous auriez besoin d'au moins 3 processeurs (ou processus) pour cela: l'un joue le rôle de vous, 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). Au collège, beaucoup de mes camarades de classe n'ont pas compris pourquoi l'interface graphique se bloque lorsqu'un bouton-poussoir effectue une opération coûteuse.
Je pense donc qu'une conception orientée objet peut décrire assez bien le monde, mais ce n'est pas la meilleure abstraction pour l'ordinateur.
Afin de gérer la complexité, nous devons regrouper les fonctionnalités en modules, et c'est un problème difficile en général. C'est comme le vieil adage sur le capitalisme, OOP est le pire système pour organiser les logiciels là-bas, à l'exception de tout ce que nous avons essayé.
La raison pour laquelle nous groupons les interactions à l'intérieur des noms, même s'il y a souvent une ambiguïté avec lequel des deux noms pour le regrouper, est que la quantité de noms se trouve dans des classes de taille gérable, tandis que le regroupement par verbes tend à produire de très petits groupes comme des éléments uniques ou de très grands groupes pour une fonction comme afficher. Les concepts de réutilisation comme l'héritage s'avèrent également beaucoup plus faciles lors du regroupement par noms.
De plus, la question de décider s'il faut mettre afficher avec la fenêtre ou le texte est presque toujours beaucoup plus claire en pratique qu'en théorie. Par exemple, presque tous les kits d'outils GUI regroupent ajouter avec le conteneur, mais afficher 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 pensez de manière abstraite, les deux méthodes semblent interchangeables.
Compte tenu de ces problèmes, comment/pourquoi est-il arrivé que la façon de faire actuellement courante OOP soit devenue si populaire? Et que peut-on faire, le cas échéant, pour la détrôner?
La POO est devenue populaire car elle 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 qui avait 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 façon procédurale de reprendre OO principes un à la fois. ou deux.
Pour détrôner l'OO, créez un langage qui facilite la transition incrémentielle de ce que la plupart des programmeurs connaissent aujourd'hui (principalement procédural, avec un peu d'OO) vers votre paradigme préféré. Assurez-vous qu'il fournit des API pratiques pour effectuer des tâches courantes et faites-en la promotion. Les gens vont bientôt créer des programmes X-in-name uniquement dans votre langue. Ensuite, vous pouvez vous attendre à ce que cela prenne des années et des années pour que les gens deviennent vraiment capables de faire X.
Jetez un oeil à DCI (données, contexte et interaction) inventé par l'inventeur du modèle MVC.
Le but de DCI est (cité de Wikipedia):
- Donnez le comportement du système le statut de première classe, au-dessus des objets (noms).
- Séparer proprement le code pour changer rapidement le comportement du système (ce que fait le système) du code pour changer lentement les connaissances du domaine (ce que le système est), au lieu de combiner les deux dans une interface de classe.
- Soutenir un style de pensée objet proche des modèles mentaux des gens plutôt que le style de pensée de classe.
Voici un bon article des 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 semble très naturel.
On peut souvent entendre que OOP correspond naturellement à la façon dont les gens pensent du monde. Mais je serais 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 non plus. Néanmoins, je pense que Nygaard et Dahl sont ceux qui l'ont dit ainsi, et je pense qu'ils se sont concentrés sur la façon dont il était plus facile de penser à la conception de simulations par rapport aux alternatives de l'époque.
(...) mais l'objectif de OOP est de concevoir des classes individuelles et leurs hiérarchies.
Cette affirmation pénètre dans un territoire sensible étant donné la façon dont les idées fausses populaires de OOP sont, et la sensibilité OO est à la définition. J'ai plus de dix ans dans le domaine, faisant à la fois le travail de l'industrie et la recherche universitaire sur les langues prog., et je peux vous dire que j'ai passé de nombreuses années à désapprendre le "courant dominant OO" parce que j'ai commencé à remarquer à quel point il était différent (et inférieur) de ce que visaient les créateurs précédents. Pour un style moderne, traitement à jour du sujet Je me réfère à l'effort récent de W. Cook:
"Une proposition pour des définitions simplifiées et modernes de" objet "et" orienté objet " http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html
Compte tenu de ces problèmes, comment/pourquoi est-il arrivé que la façon de faire actuellement courante OOP soit devenue si populaire?
Peut-être la même raison QWERTY sont devenus populaires ou la même raison pour laquelle le système d'exploitation DOS est devenu populaire. Les choses ne font que rouler sur des véhicules populaires, malgré leurs propriétés, et deviennent elles-mêmes populaires. Et parfois, des versions similaires mais pires de quelque chose sont considérées comme la réalité.
Et que peut-on faire, le cas échéant, pour le détrôner?
Écrivez un programme en utilisant une approche supérieure. Écrivez le même programme en utilisant une approche OO. Montrer que le premier a de meilleures propriétés que le dernier dans tous les aspects qui sont significatifs (à la fois les propriétés du système lui-même et les propriétés d'ingénierie). Montrer que le programme choisi est pertinent et l'approche proposée maintient 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 si nécessaire.
Enfin, partagez vos découvertes avec nous.