OOP remplit-il la promesse de réutilisation de code? Quelles sont les alternatives pour réaliser la réutilisation de code?
La réutilisation du code est peut-être la plus grande promesse d'utiliser le paradigme orienté objet. Certains contestent la réalisation de cet objectif. Pourquoi a-t-il (non) été réalisé?
Le code est-il réutilisé comme OOP le définit, rend les projets plus productifs?
Ou plus gérable? Ou plus facile à entretenir? Ou avec plus de qualité?
Nous sommes probablement tous d'accord pour dire que la réutilisation de code est une bonne chose, mais il existe plusieurs façons d'atteindre cet objectif. La question porte sur la méthode de réutilisation du code proposée par OOP. C'était une bonne chose? Existe-t-il de meilleures méthodes pour réutiliser le code que l'orientation d'objet, la sous-classification, le polymorphisme, etc.? Quelles sont les meilleures façons? Pourquoi?
Racontez-nous votre expérience avec la réutilisation OOP ou d'autres paradigmes.
La réutilisation du code est une assez bonne idée. Pas génial.
J'ai une perspective tirée d'environ 30 ans d'ingénierie logicielle, essayant de "réutiliser".
J'ai commencé à enquêter sur la "réutilisation du code" comme sujet de recherche dans les années 80, après avoir découvert que j'avais réutilisé la conception d'un système d'exploitation que j'ai construit au début des années 70, pour un autre système d'exploitation que j'ai construit à la fin des années 70.
La bonne partie de la réutilisation du code est la possibilité de réutiliser parfois du code préexistant honnête à Dieu. Mais le monde est plein de code; comment trouver ce que vous cherchez? Voici ce que j'appelle la malédiction de réutilisation :
Je suis le Père Noël (ok Open Source), et j'ai un sac de 1 milliard de composants logiciels. Vous pouvez en avoir n'importe lequel.
Bonne chance pour choisir.
Pour bien résoudre le problème de réutilisation:
- le réutilisateur doit en quelque sorte spécifier ce dont il a besoin (fonctionnellement, performances, langage cible, hypothèses d'environnement, ...)
- il doit y avoir une bibliothèque de code "réutilisable" qui a été indexé de diverses manières par ces critères potentiels
- un mécanisme doit exister pour sélectionner les éléments candidats (pour un milliard d'éléments, vous ne pouvez pas tous les regarder personnellement)
- il doit y avoir un moyen de caractériser à quelle distance de la spécification les candidats choisis sont
- un processus régulier devrait exister pour permettre au réutilisateur de modifier le code réutilisable choisi (voici la plus grande contribution d'OOP: vous pouvez modifier un composant/objet existant en remplaçant ses emplacements. OOP ne fournit aucun autre aide).
- tout cela doit clairement être moins cher que simplement le recoder
La plupart du temps, ce qui a été découvert au fil des ans, c'est que pour que le code soit réutilisable, il doit en quelque sorte être conçu à cette fin, ou il contient trop d'hypothèses implicites. Les bibliothèques de réutilisation de code les plus réussies sont en fait assez petites. On peut dire que les bibliothèques et les frameworks sont du code "réutilisable" et sont extrêmement efficaces; Java et C # réussissent non pas parce qu'ils sont de très bons langages informatiques, mais plutôt parce qu'ils ont d'énormes bibliothèques bien conçues, implémentées et documentées disponibles. Mais les gens ne regardent pas le code source dans le bibliothèques; ils appellent simplement une API bien documentée (conçue pour être généralement utilisable).
Ce que la réutilisation du code n'a pas fait (POO non plus) est de fournir des ordres de grandeur d'amélioration de notre capacité à coder les systèmes.
Je pense que le principal défaut est que tout type de réutilisation de code est fondamentalement limité car le code a trop d'hypothèses intégrées . Si vous réduisez le code, vous minimisez les hypothèses, mais le coût de construction à partir de zéro n'est pas très important et les gains de réutilisation ne sont pas efficaces. Si vous faites des blocs de code énormes, ils sont à peu près inutiles dans un nouveau contexte. Comme Gulliver, ils sont liés à la plage par un million de minuscules cordes, et vous ne pouvez tout simplement pas vous permettre de les couper tous.
Ce sur quoi nous devrions travailler est la réutilisation des connaissances pour construire du code . Si nous pouvons le faire, alors nous pouvons appliquer ces connaissances pour construire le code dont nous avons besoin, en manipulant l'ensemble actuel d'hypothèses.
Pour ce faire, il faut toujours la même capacité de spécification pour caractériser les composants logiciels (vous devez toujours dire ce que vous voulez!). Mais ensuite, vous appliquez cette connaissance de "construction" aux spécifications pour générer le code que vous voulez.
En tant que communauté, nous ne sommes pas encore très bons dans ce domaine. Mais les gens le font tout le temps; pourquoi ne pouvons-nous pas l'automatiser? Il y a beaucoup de recherches, et cela montre que cela peut être fait dans de nombreuses circonstances.
Un élément clé de la machinerie nécessaire pour cela est des outils mécaniques pour accepter les "descriptions de composants" (ce ne sont que des documents formels et peuvent être analysés comme des langages de programmation) et appliquer transformations de programme = pour eux.
Les compilateurs le font déjà: -} Et ils sont vraiment bons dans la classe de problèmes qu'ils abordent.
Les modèles UML avec génération de code sont une tentative pour ce faire. Pas une très bonne tentative; à peu près ce que l'on dit dans la plupart des modèles UML est "J'ai des données qui ressemblent à ceci". Assez difficile de générer un vrai programme si la fonctionnalité est omise.
J'essaie de construire des systèmes de transformation de programmes pratiques, un outil appelé DMS . J'ai été assez bien distrait par l'application de transformations de programme non pas tant aux spécifications abstraites pour générer du code, mais plutôt au code hérité pour le nettoyer. (Ce sont les mêmes problèmes dans l'abstrait!). (Construire de tels outils prend beaucoup de temps; je le fais depuis 15 ans et en attendant, vous devez manger).
Mais DMS a les deux propriétés clés que j'ai décrites ci-dessus: la capacité de traiter des spécifications formelles arbitraires et la capacité de capturer des "connaissances de génération de code" sous forme de transformations et de les appliquer à la demande. Et remarquablement, nous générons dans certains cas spéciaux, du code plutôt intéressant à partir des spécifications; DMS est en grande partie construit en utilisant lui-même pour générer son implémentation. Cela nous a permis de réaliser au moins une partie de la promesse de réutilisation (des connaissances): des gains de productivité extrêmement importants. J'ai une équipe d'environ 7 personnes techniques; nous avons écrit probablement 1-2 MSLOC de "spécifications" pour DMS, mais nous avons 10MSLOC de code généré.
Résumé: réutilisation des connaissances de génération est la victoire, pas réutilisation du code.
La réutilisation du code est obtenue en OOP mais elle est également réalisée en programmation fonctionnelle. Chaque fois que vous prenez un bloc de code et le rendez appelable par le reste de votre code afin que vous puissiez utiliser cette fonctionnalité ailleurs est la réutilisation du code.
Ce type de réutilisation de code rend également le code plus facile à gérer car la modification de ce bloc appelable modifie tous les endroits où il est appelé. Je dirais que ce résultat a également augmenté la qualité et la lisibilité.
Je ne suis pas sûr que OOP est simplement là pour fournir la réutilisation du code. Je regarde OOP comme plus un moyen d'interagir avec des objets et d'abstraire les détails de la structure des données.
La programmation orientée objet a des racines qui remontent aux années 1960. À mesure que le matériel et les logiciels devenaient de plus en plus complexes, la facilité de gestion devenait souvent une préoccupation. Les chercheurs ont étudié les moyens de maintenir la qualité des logiciels et développé une programmation orientée objet en partie pour résoudre les problèmes courants en mettant fortement l'accent sur les unités discrètes et réutilisables de la logique de programmation [citation nécessaire]. La technologie se concentre sur les données plutôt que sur les processus, avec des programmes composés de modules autonomes ("classes"), dont chaque instance ("objets") contient toutes les informations nécessaires pour manipuler sa propre structure de données ("membres"). Cela contraste avec la programmation modulaire existante qui était dominante depuis de nombreuses années et qui se concentrait sur la fonction d'un module, plutôt que spécifiquement sur les données, mais également prévue pour la réutilisation de code et des unités réutilisables autosuffisantes de logique de programmation, permettant la collaboration grâce à l'utilisation de modules liés (sous-programmes). Cette approche plus conventionnelle, qui persiste toujours, a tendance à considérer les données et le comportement séparément.
Oui et Non
La réutilisation du code est un terme fourre-tout pour de nombreuses activités différentes.
- Réutilisation de code dans un seul projet. OO est parfaitement adapté à cela, une application bien conçue aura cartographié de près les relations du monde modélisé, éliminant ainsi le code en double autant que possible et conseillé. Cependant, vous pouvez affirmer que les technologies pré-OO pourraient réaliser la même chose, ce qui est vrai, mais OO est à bien des égards plus pratique.
- Bibliothèques tierces Cela semble fonctionner aussi bien avec ou sans OO.
- Réutilisation de code polyvalente La plus grande promesse de réutilisation de code de OO était que le code, une fois écrit pour une application peut être réutilisé plus tard pour une autre, ce qu'il n'avait pas fait été spécialement conçu pour. C'était à la mode lorsque la notion de OO a filtré à travers les portes des bureaux de gestion supérieurs, et OO complètement échoué à y parvenir). Il s'est avéré que le but était un aspect crucial de la conception OO (et peut-être tout le code procédural, mais ce n'est que ma théorie)) et les tentatives de réutilisation du code se sont soldées par des désastres de maintenance. un ancien framework que personne n'ose modifier et son ami, les frameworks légèrement différents pour chaque application proviennent généralement d'ici.)
Je suis d'accord avec Chris, la programmation fonctionnelle est un bon moyen de réutiliser le code.
De nombreux programmes ont des structures de code récurrentes. Pour cela, certains modèles de conception sont utilisés dans le monde OOP, mais cela peut être réalisé par fonctions récursives et correspondance de motifs dans les langages de programmation fonctionnels. Pour plus d'informations à ce sujet, voir le premier chapitre dans Programmation fonctionnelle du monde réel .
Je pense que l'héritage profond de OOP peut être trompeur dans de nombreux cas. Vous avez une classe et de nombreuses méthodes étroitement liées sont implémentées dans différents fichiers. Comme Joe Armstrong dit à propos de la POO:
Le problème avec les langages orientés objet est qu'ils ont tout cet environnement implicite qu'ils emportent avec eux. Vous vouliez une banane mais ce que vous avez obtenu était un gorille tenant la banane et toute la jungle.
Les fonctions d'ordre élevé sont également très utiles en matière de réutilisation de code, par exemple map et foldr qui est le fondement de Google MapReduce .
Le passage de messages asynchrones est également un bon moyen d'organiser des logiciels complexes, et certains informaticiens affirment que les objets étaient supposés communiquer entre eux de manière asynchrone comme dans le Dites, ne demandez pas OOP principe. Voir plus à ce sujet dans Programmation orientée objet: le mauvais chemin? étaient Joe Armstrong est cité:
J'ai commencé à me demander ce qu'était la programmation orientée objet et je pensais qu'Erlang n'était pas orienté objet, c'était un langage de programmation fonctionnel. Ensuite, mon directeur de thèse a dit "Mais vous vous trompez, Erlang est extrêmement orienté objet". Il a dit que les langages orientés objet ne sont pas orientés objet. Je pourrais penser, bien que je ne sois pas sûr de le croire ou non, mais Erlang pourrait être le seul langage orienté objet parce que les 3 principes de la programmation orientée objet sont qu'il est basé sur le message en passant , que vous avez l'isolement entre les objets et que vous avez polymorphisme .
Le passage de messages asynchrones comme dans les systèmes pilotés par les événements et dans Erlang est également un très bon moyen de découpler les systèmes et le couplage lâche est important dans les systèmes complexes. Avec un système suffisamment découplé, vous pouvez faire évoluer le système pendant son fonctionnement, peut-être sur différents nœuds. Unibet a fait une excellente présentation à ce sujet: Domain Event Driven Architecture
Cependant, je pense que la plupart de la réutilisation du code se fait en utilisant des bibliothèques et des frameworks.
Je posterais une longue réponse mais pourquoi? Udi Dahan l'explique beaucoup mieux que moi.
http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/
Voici le début de l'article:
Cette industrie est préoccupée par la réutilisation.
Il y a cette conviction que si nous réutilisions simplement plus de code, tout irait mieux.
Certains vont même jusqu'à dire que tout le point d’orientation de l’objet était une réutilisation - ce n’était pas le cas, l’encapsulation était la grande chose. Après cette orientation des composants, c'était la chose qui était censée permettre la réutilisation. Apparemment, cela n'a pas si bien fonctionné non plus, car ici, nous mettons maintenant nos espoirs réutilisables sur l'orientation service.
Des livres entiers de modèles ont été écrits sur la façon de réutiliser avec l'orientation de la journée. Les services ont été classés dans tous les sens pour y parvenir, des services d'entité aux services d'activité en passant par les services de processus et les services d'orchestration. La composition de services a été présentée comme la clé de la réutilisation et de la création de services réutilisables.
Je pourrais aussi bien vous révéler le sale petit secret:
La réutilisation est une erreur
L'humble pipe Unix a fait plus pour la réutilisation du code que tout ce qui s'est passé. Les objets se sont avérés être un moyen intuitif de structurer le code lorsqu'ils sont arrivés et plus tard, les gens ont commencé à s'attaquer à tout et n'importe quoi. En général, les objets sont destinés à l'encapsulation et non à la réutilisation de code, la réutilisation de code nécessite quelque chose de plus et la hiérarchie d'héritage de classe est un mauvais substitut à ce que devrait être réellement un mécanisme de réutilisation de code.
La POO n'est pas spéciale; vous pouvez créer du code réutilisable avec ou sans POO. Les fonctions pures sont particulièrement réutilisables: par exemple, Java.lang.math.sqrt(double) prend un nombre et donne un nombre. Pas de POO, mais certainement plus réutilisable que la plupart des codes disponibles.
Du point de vue de la programmation fonctionnelle OOP concerne principalement la gestion de l'état.
Dans la programmation fonctionnelle, vous pouvez facilement avoir des centaines de fonctions utiles pour les listes: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html .
Auriez-vous des centaines de méthodes dans une classe List? Les méthodes publiques sont considérées comme une interface avec l'état interne que vous souhaitez conserver petit.
Malheureusement, au lieu de (ré) utiliser beaucoup de petites fonctions, certaines personnes dupliquent les fonctionnalités. Pour moi, c'est parce que OOP n'encourage pas la réutilisation du code autant que la programmation fonctionnelle.
Pour moi, oui, mais pas tout le temps, et cela aurait pu se faire autrement.
La plupart du temps, en créant une classe de base abstraite et en créant des implémentations concrètes de cette classe.
De nombreux frameworks utilisent également l'héritage pour fournir la réutilisation du code (Delphi, Java, .Net ne sont que quelques-uns qui viennent immédiatement à l'esprit).
Cela ne veut pas dire que de nombreuses bibliothèques d'utilitaires et des extraits de code n'auraient pas pu faire le travail également, mais il y a quelque chose de plaisant dans une hiérarchie d'objets bien conçue.
D'après mon expérience, j'ai eu plus de succès à tirer parti du code "réutilisable" grâce à des fonctionnalités de programmation génériques (comme les modèles C++) que je n'en ai eu en utilisant les principes OOP comme les hiérarchies d'héritage).
La POO est trop ouverte pour une réutilisation efficace.
Il y a trop de façons de réutiliser. Chaque classe publique demande: "créer une nouvelle instance de moi!", chaque méthode publique dit: "appelez-moi!", chaque méthode protégée donne: = "remplacez-moi!" - et toutes ces façons de réutiliser sont différentes , elles ont des paramètres différents, elles apparaissent dans différents contexte, tous ont leurs différentes règles, comment l'appeler/étendre/remplacer.
[~ # ~] api [~ # ~] est mieux, c'est un sous-ensemble strict de OOP (ou non -oop), mais dans la vraie vie, les API sont sur-dotées et ne cessent de croître, il y a encore trop de points de connexion. De plus, une bonne API peut vous faciliter la vie, c'est le meilleur moyen de fournir une interface pour la POO.
Le paradigme Datadlow fournit une interface stricte pour les composants, ils ont des ports des types suivants:
- les consommateurs (intrants), et
- producteurs (extrants).
Cela dépend du domaine, il existe certains types de paquets, de sorte que les consommateurs et les producteurs peuvent y être connectés avec des ports identiques (ou compatibles). La plus belle partie de celui-ci, cela peut être fait visuellement, car il n'y a pas de paramètres ou de réglages sur les connexions, ils connectent vraiment un consommateur et un producteur.
J'étais un peu flou, vous pouvez jeter un oeil sur balise "dataflow" sur StackOverflow , ou Wikipedia "programmation datafow" ou Wikipedia "programmation basée sur les flux " .
(De plus, j'ai écrit un système de flux de données, en C++. Donc OOP et DF ne sont pas des ennemis, DF est une méthode d'organisation de niveau supérieur.)
Dans CommonLisp, il existe de nombreux moyens pour parvenir à une réutilisation:
typage dynamique, avoir votre code générique par défaut
abstractions impératives, c'est-à-dire sous-programmes
orientation objet, avec héritage multiple et répartition multiple
syntaxe-abstraction, la capacité de définir de nouvelles constructions syntaxiques ou d'abréger du code de plaque de chaudière
abstractions fonctionnelles, fermetures et fonctions d'ordre élevé
Si vous essayez de comparer l'expérience CommonLisp à d'autres langages, vous verrez que la principale caractéristique qui facilite la réutilisation du code est la présence de les deux abstractions orientées objet et fonctionnelles. Ils sont plus complémentaires qu'alternatifs: sans l'un d'eux, vous êtes obligé de réimplémenter les fonctionnalités manquantes de manière maladroite. Voir, par exemple, les classes de foncteurs utilisées comme fermetures et correspondance de modèles pour obtenir une répartition de méthode non extensible.
La POO vous donne plus façons de réutiliser le code. C'est tout.
Il n'y a vraiment pas de "réutilisation" telle que les gens la décrivent. La réutilisation est une propriété accidentelle de quoi que ce soit. Il est difficile de planifier cela. Ce que la plupart des gens veulent dire quand ils parlent de "réutilisation", c'est "utilisation". C'est un terme beaucoup moins attrayant et excitant. Lorsque vous utilisez une bibliothèque, vous l'utilisez normalement pour ce à quoi elle était destinée. Vous pas le réutilisez à moins que vous ne fassiez quelque chose de vraiment fou.
En ce sens, la réutilisation dans le monde réel consiste à réorienter les choses. Je peux réutiliser ces sièges ici et les réorganiser pour former ... un lit! Pas un lit très confortable, mais je peux le faire. Ce n'est pas leur utilisation principale. Je les réutilise en dehors de leur domaine d'application d'origine. [...] Demain, je reviendrai au Royaume-Uni. Je vais pas réutiliser l'avion. Je vais juste l'utiliser pour l'usage auquel il était destiné, il n'y a rien d'extraordinaire ni d'excitant à cela.
- Kevlin Henney
Réutilisation horizontale: aspects, traits, greffes
Classic OO échoue parfois sur la réutilisation de code, spécialement lorsque vous devenez fou d'héritage faute d'un meilleur moyen de partager les fonctionnalités réelles entre les classes. Pour ce problème, des mécanismes de réutilisation horizontale ont été créés, tels que comme AOP, traits et greffes.
Programmation orientée aspect
Je considère AOP comme la demi-orange manquante de OOP. L'AOP n'est pas vraiment connu, mais il a atteint le code de production.
Je vais essayer de l'expliquer en termes simples: imaginez que vous pouvez injecter et filtrer des fonctionnalités avec une structure spéciale appelée un aspect, ces aspects ont des "méthodes" qui définissent quoi et comment va être affecté par réflexion , mais au moment de la compilation, ce processus est appelé tissage .
Un exemple serait un aspect qui dit "pour toutes les méthodes de certaines classes qui commencent par get, votre programme va écrire dans un fichier journal les données qui ont été obtenues et l'heure à laquelle elles ont été obtenues".
Regardez ces deux conférences si vous voulez mieux comprendre l'AOP:
- tilisation de la programmation orientée aspect pour empêcher les attaques d'applications 1/6
- Programmation Orientée Aspect: Recherche Radicale en Modularité par Gregor Kiczales (l'homme principal derrière AOP)
Traits et greffes
Traits sont une autre construction pour définir du code réutilisable qui complète la POO, ils sont similaires à mixins , mais plus propres.
Plutôt que de les expliquer, il y a n grand PHP RFC qui explique les deux . Les traits arrivent à PHP btw, ils sont déjà engagé dans le coffre.
En résumé
La POO est la clé de la modularité, à mon avis et comme nous le savons couramment aujourd'hui La POO est encore incomplète .
Je vais risquer le ridicule et avouer, je n'utilise que OOP très récemment. Cela ne me vient pas automatiquement. La plupart de mon expérience implique des bases de données relationnelles, donc je pense tables et jointures. On prétend qu'il vaut mieux l'apprendre dès le début, ce qui évite d'avoir à recâbler votre réflexion en ce qui concerne la programmation. Je n'ai pas ce luxe et je refuse d'abandonner ma carrière sur une théorie de la tour d'ivoire. Comme tout le reste, je vais le découvrir.
Au début, je pensais que tout le concept n'avait pas de sens. Cela semblait tout simplement inutile et trop difficile. Je sais, c'est un discours fou. Évidemment, il faut un certain niveau de compréhension avant de pouvoir apprécier les avantages de quoi que ce soit ou de le rejeter pour de meilleures méthodes.
La réutilisation du code nécessite une volonté de ne pas répéter le code, une compréhension de la façon de l'accomplir, une planification initiale. Devriez-vous éviter de réutiliser du code lorsque vous avez décidé que vous avez un cas où cela n'en vaut pas la peine? Et aucun langage n'est si strictement OO qu'il générera une erreur lorsqu'il pensera que vous devriez avoir hérité du code d'une autre classe. Au mieux, ils fournissent un environnement propice à sa mise en œuvre.
Je pense que le plus grand avantage de OOP est l'acceptation générale de la façon dont le code doit être organisé. Tout le reste est pesant. Une équipe de programmeurs peut ne pas être entièrement d'accord sur la façon dont toutes les classes doivent être structurées, mais ils devraient pouvoir trouver le code.
J'ai vu suffisamment de code procédural pour savoir qu'il pourrait être n'importe où, et parfois il est partout.
En lisant les articles ci-dessus, quelques remarques:
- Beaucoup pensent que la réutilisation de code dans OOP implique l'héritage. Je ne suis pas d'accord. Les interfaces et les contrats sont au cœur de la réutilisation de code dans OOP systèmes. OOP est une tentative de boîte grise dans la création d'une technologie de composant.
- La différence entre les "frameworks" spécifiques à un domaine et génériques comme sujet de réutilisation me semble trop abstraite. À mon avis, un composant (un contrat d'interface concis, minimal et réutilisable et l'implémentation derrière) ne peut être fait que si le problème qu'il traite est bien compris. Un composant spécifique au domaine, qui permet aux experts non spécialisés de faire leur travail avec moins de connaissances sur le domaine, est un composant (ré) utile. Les utilisateurs doivent comprendre l'interface, moins les subtilités du domaine problématique.
- Niveaux de réutilisation souvent oubliés: réutilisation d'idées, réutilisation de spécifications, réutilisation d'architecture/conception, réutilisation d'interface, réutilisation de cas de test. La réutilisation du code n'est pas toujours favorable. Mais c'est souvent un gros gain de temps de s'en tenir à une architecture spécifique pour s'attaquer à un nouveau produit similaire.
- Les modèles de conception OOP (Gamma et al.) Ont élaboré à mes yeux des techniques de mise en œuvre tactique plutôt que d'être significatifs dans le contexte de la réutilisation de code à plus grande échelle. Ils aident à écrire une application avec OOP éléments, pourtant je ne les verrais pas comme une solution à la question de "réutilisation du code" au-delà d'une seule application.
- Ce n'est peut-être pas juste: 20 ans d'expérience en C/C++/C # et 6 mois de programmation fonctionnelle (F #). Un élément majeur pour permettre la réutilisation est le suivant: les gens doivent trouver facilement "l'interface", l'étudier, la comprendre, puis l'utiliser. La programmation fonctionnelle pure ne me permet pas de voir facilement la structure, les candidats à la réutilisation ou où tout commence et où tout se termine. Le "sucre syntaxique" tant apprécié est souvent du sel dans mes yeux, m'empêchant de voir facilement ce qui se passe. Ainsi, j'essaierais moins probablement de réutiliser une fonctionnalité (qu'est-ce - un tas de fonctions?), Qui peut avoir des effets secondaires cachés que je ne peux même pas voir (évaluation paresseuse, monades, ...). Ne vous méprenez pas, la programmation fonctionnelle a des côtés très sympas, mais toutes les forces proclamées que je vois avec une bonne dose de doute. Je suis très curieux de savoir ce que l'avenir post-fonctionnel apporte et j'espère le voir avant de prendre ma retraite;)
- La spécification, la conception et la mise en œuvre sont des vues couplées mais pas facilement traversables sur la "même chose". Pour combler la productivité future, il est beaucoup plus vital qu'un nouveau paradigme de programmation de combler l'écart, d'augmenter (raisonnement automatisé, traçabilité) les avantages mutuels entre ces vues. Les langages de spécifications formalisés, les notations de test standardisées (par exemple ttcn3) et les langages de programmation prenant en charge la vérification des interfaces et des contrats par rapport aux spécifications sans mise en commentaire peuvent être ce dont nous avons le plus besoin de toute urgence.
Le problème est à mon humble avis plus subtil:
- La POO est un excellente méthode pour structurer du code avec un état mutable. En encapsulant l'état dans des objets, le code impératif de l'état devient plus compréhensible car, par exemple, si un morceau d'état est exprimé en tant que champs privés d'une classe, vous savez que au moins ce morceau particulier de l'état ne peut être modifié que par les méthodes de cette classe. (Et vous pouvez facilement casser cet avantage en abusant de l'héritage, btw.) C'est maintenant suffisant, mais waaay mieux que de ne pas avoir même cela.
- le code avec un état mutable est intrinsèquement difficile à réutiliser. Bien plus difficile que le code utilisant des structures de données immuables.
Donc OOP en soi n'est pas mauvais de faire du code réutilisable pov, mais les types de code qui sont écrits en utilisant OOP sont intrinsèquement difficiles à réutiliser.
En outre, programmation fonctionnelle peut entraîner un code plus réutilisable . Mais obtenir les abstractions pour écrire un code fonctionnel sain tout en respectant une date limite peut ne pas être réalisable. Et les abstractions "à moitié à droite" seront plus faciles à exprimer OOP style. Et cela n'aura pas tendance à rendre plus facile à réutiliser le code - un niveau d'abstractions plus élevé signifie que la compréhension du code nécessitera un investissement initial plus élevé de la capacité cognitive limitée des programmeurs.
Comme exemple pratique: Le code du jeu implique beaucoup d'état mutable, car c'est la façon naturelle de penser à coder un jeu, à moins qu'il ne soit très puzzle/algorithmique, donc il finit évidemment par être structuré en utilisant OO. Et bien sûr, c'est difficile à réutiliser. Mais le même code, contenant les mêmes connaissances, serait encore plus difficile à réutiliser sans POO. Et le réécrire pour être un style fonctionnel pourrait nécessiter de changer totalement la façon dont vous pensez de ce code, les connaissances derrière. Oui, le résultat la connaissance derrière le code serait beaucoup plus claire après la OO to FP réécriture peut-être ... mais le coût pourrait être énorme et ce pourrait être le type de coût qui devrait également être payé par les gens souhaitant réutiliser le code incroyablement intelligent et bien abstrait avec lequel vous vous retrouvez , paradoxalement, les gens finiraient par ne pas réutiliser le code, même si techniquement il est plus réutilisable.
... ce qui conduit à la dernière subtilité: la réutilisation du code concerne l'interface People | Code, pas seulement le code. OOP fait un travail décent de servir cette interface car elle correspond bien avec combien de personnes pensent à de nombreux types de code écrit de nos jours. FP pourrait être mieux pour le code réutiliser, mais à mon humble avis pas pour réutiliser facilement le type de code que les gens ont réellement besoin d'écrire de nos jours. Cela changera selon le type de code que nous devons écrire des modifications.
P.S. Et si quelqu'un veut dire que "OO ne concerne pas un état mutable, vous pouvez également avoir OO avec un état immuable" ... J'appelle cela "FP en utilisant des classes comme espaces de noms". C'est génial quand cela fonctionne pour vous et évite certaines lacunes des systèmes de modules de certains langages et peut entraîner un code plus réutilisable. Mais ce n'est pas OO;)
POO Fournit un ensemble d'outils utiles qui vous permettent d'écrire du code qui peut être utilisé à plus d'endroits que vous ne pourriez en avoir sans ces outils. Si vous écrivez une fonction PrintIt qui prend n'importe quel ancien objet et appelle .toString() dessus, vous aurez ré-utilisé ce code dès que vous l'appelerez avec plus d'un type d'objet. Avec ces outils, chaque ligne de code en fait plus.
La programmation fonctionnelle est très chaude en ce moment parmi les hipsters. Il vous fournit un ensemble d'outils complet pour que chaque ligne de code en fasse plus. Ce n'est probablement pas mieux ou fonctionne, mais fournit un autre outil dans la boîte à outils.
(Il y avait une idée folle pour tout un niveau supplémentaire de réutilisation orientée objet: L'idée était que nous pouvions définir une seule classe Customer et l'utiliser dans chaque application que nous avons écrite. Ensuite, les applications seraient juste un peu coller ici et là. Cela n'a pas fonctionné. Mais cela ne signifie pas que OO a échoué, ou même que la réutilisation a échoué. Les types de base de réutilisation de code dans les applications ont rendu possible pour écrire des applications qui ont fait plus et pour les écrire plus rapidement.)