La réutilisation du code est peut-être la plus grande promesse d'utiliser un paradigme orienté objet. Certains contestent que cela a été réalisé. Pourquoi a-t-il (non) été atteint?

Est-ce que la réutilisation de code telle que définie par la POO 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 du code est une bonne chose, mais il existe plusieurs façons d'atteindre cet objectif. La question concerne la méthode de réutilisation de code proposée par OOP. Était-ce une bonne chose? Existe-t-il de meilleures méthodes de réutilisation du code que l'orientation d'objet, la sous-classification, le polymorphisme, etc.? Quels sont les meilleurs moyens? Pourquoi ?

Racontez-nous votre expérience de la réutilisation de la POO ou d'autres paradigmes.

La réutilisation du code est une très bonne idée. Pas terrible .

J'ai une perspective tirée d'environ 30 ans d'ingénierie logicielle, qui tente de "réutiliser".

J'ai commencé à étudier la «réutilisation de code» comme sujet de recherche dans les années 80, après avoir découvert que j'avais réutilisé le design d'un système d'exploitation que j'avais construit au début des années 70, pour un autre installé à la fin des années 70.

La bonne partie de la réutilisation de code réside dans la possibilité de réutiliser parfois du code préexistant «dieu-dieu». Mais le monde est plein de code; comment trouver ce que tu veux 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 d'un milliard de composants logiciels. Vous pouvez avoir n'importe lequel d'entre eux.

Bonne chance pour choisir.

Pour résoudre correctement le problème de réutilisation:

• le ré-utilisateur doit en quelque sorte spécifier ce dont il a besoin (fonctionnellement, performances, langue cible, hypothèses d'environnement, ...)
• il doit exister une bibliothèque de code "réutilisable" qui a été indexée de différentes manières par ces critères potentiels
• il doit exister un mécanisme pour sélectionner les éléments candidats (pour un milliard d'éléments, vous ne pouvez pas tous les examiner personnellement)
• il doit y avoir un moyen de caractériser à quelle distance de la spécification les candidats choisis sont
• Un processus régulier doit exister pour permettre au réutilisateur de modifier le code réutilisable choisi (voici la contribution la plus importante de la POO: vous pouvez modifier un composant / objet existant en remplaçant ses emplacements. La POO ne fournit aucune autre aide).
• tout cela doit être nettement moins cher que de le recoder

La plupart du temps, on a découvert au fil des ans que pour que le code soit réutilisable, il doit en quelque sorte être conçu dans ce but, ou il contient trop d'hypothèses implicites. Les bibliothèques les plus réussies de réutilisation de code ont été plutôt petites. On peut soutenir que les librairies et les frameworks sont du code "réutilisable" et qu'ils ont un grand succès; Java et C # réussissent non pas parce qu’ils sont de très bons langages informatiques, mais plutôt parce qu’ils disposent d’énormes bibliothèques bien conçues, implémentées et documentées. Mais les gens ne regardent pas le code source dans les bibliothèques; ils appellent simplement une API bien documentée (conçue pour être généralement utilisable).

Ce que la réutilisation de code n’a pas encore fait (la POO non plus), c’est améliorer considérablement notre capacité à coder les systèmes.

Je pense que le principal inconvénient est que tout type de réutilisation de code est fondamentalement limité car le code contient trop d'hypothèses intégrées . Si vous réduisez le code de façon minuscule, vous réduisez les hypothèses au minimum, mais le coût de la création à partir de zéro n'est pas très élevé et les gains de réutilisation ne sont pas efficaces. Si vous créez des morceaux de code énormes, ils sont quasiment inutiles dans un nouveau contexte. Comme Gulliver, ils sont attachés à la plage par un million de petites ficelles, et vous ne pouvez tout simplement pas vous permettre de tous les couper.

Nous devrions travailler sur la réutilisation des connaissances pour construire du code . Si nous pouvons faire cela, alors nous pouvons appliquer cette connaissance à la construction du code dont nous avons besoin, en gérant l'ensemble actuel des 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 souhaité.

En tant que communauté, nous ne sommes pas encore très bons à cela. 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.

Les outils mécaniques nécessaires pour accepter les "descriptions de composants" (ce ne sont que des documents formels et peuvent être analysés comme des langages de programmation) constituent un élément clé de cette machinerie et leur appliquent des transformations de programme .

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 constituent une tentative. Ce n'est 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 laissée de côté.

J'essaie de construire des systèmes pratiques de transformation de programme, un outil appelé DMS . J'ai été assez distrait en appliquant des 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 le même problème dans l'abstrait!). (Construire de tels outils prend beaucoup de temps; je le fais depuis 15 ans et en attendant, il faut 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 en matière 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 particuliers, du code plutôt intéressant provenant de 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 (du savoir): des gains de productivité extrêmement importants. J'ai une équipe d'environ 7 personnes techniques; nous avons probablement écrit 1 à 2 MSLOC de "spécifications" pour DMS, mais avons environ 10 LMS de code généré.

Résumé: la réutilisation des connaissances de la génération est la victoire, pas la réutilisation du code .

La réutilisation de code est obtenue en POO, mais également en programmation fonctionnelle. Chaque fois que vous prenez un bloc de code et que vous le rendez appelable par le reste de votre code, de telle sorte que vous puissiez utiliser cette fonctionnalité ailleurs, cela constitue une 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 emplacements auxquels il est appelé. Je dirais que ce résultat améliore également la qualité et la lisibilité.

Je ne suis pas sûr que la programmation orientée objet soit simplement là pour permettre la réutilisation du code. Je considère la programmation orientée objet plus comme un moyen d'interagir avec des objets et d'abstraction des détails de la structure de données.

De Wikpedia:

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é des 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 insistant fortement sur les unités discrètes et réutilisables de la logique de programmation [citation nécessaire]. La technologie est axée 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 était axée sur la fonction d'un module, plutôt que sur les données, mais prévoyait également la réutilisation du code. et des unités autonomes de logique de programmation réutilisables, permettant une collaboration grâce à l'utilisation de modules liés (sous-routines). Cette approche plus conventionnelle, qui persiste toujours, tend à considérer les données et le comportement séparément.

Oui et non

La réutilisation de code est un terme fourre-tout pour de nombreuses activités différentes.

1. Réutilisation de code dans un seul projet. OO convient parfaitement à cela, une application bien conçue aura cartographié de près les relations du monde modélisé, éliminant ainsi autant que possible et en partie le code en double. Cependant, vous pouvez affirmer que les technologies pré-OO pourraient permettre d'atteindre le même objectif, ce qui est vrai, mais OO est à bien des égards plus pratique.
2. Bibliothèques tierces Cela semble fonctionner aussi bien avec ou sans OO.
3. Réutilisation de code à des fins multiples La principale promesse de OO en matière de réutilisation de code était que le code, une fois écrit pour une application, puisse ensuite être réutilisé pour une autre, pour laquelle il n'avait pas été spécifiquement conçu. C'était à la mode lorsque la notion d'OO a filtré à travers les portes des bureaux de la haute direction et que celui-ci a complètement échoué. Il s’est avéré que cet objectif était un aspect crucial de la conception d’OO (et éventuellement de tout code de procédure, mais ce n’était que ma théorie) et les tentatives de modification du code se sont soldées par des sinistres liés à la maintenance. (Les antipatterns bien connus d'un vieux 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 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 du post:

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'à prétendre que toute l'orientation de l'objet était la réutilisation - ce n'était pas le cas, l'encapsulation était la grande chose. Après cette orientation des composants, c'était ce qui était supposé permettre la réutilisation. Apparemment, cela n’a pas si bien fonctionné non plus, car nous fondons ici 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 du jour. Les services ont été classés de toutes les manières pour y parvenir: services d'entité et services d'activité, services de processus et 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

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 de la programmation orientée objet, mais cela peut être réalisé à l'aide de fonctions récursives et de correspondance de modèles dans des langages de programmation fonctionnels. Pour plus d'informations à ce sujet, voir le premier chapitre de la programmation fonctionnelle dans le monde réel .

Je pense que l'héritage profond en POO 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 l'a dit à propos de la programmation orientée objet:

Le problème avec les langages orientés objet, c'est qu'ils ont tout cet environnement implicite qu'ils transportent avec eux. Vous vouliez une banane mais vous avez eu un gorille tenant la banane et toute la jungle.

Les fonctions d'ordre élevé sont également très utiles pour la réutilisation de code, par exemple, mapet foldrconstituent le fondement de MapReduce de Google .

Le passage de messages asynchrone 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 principe Tell, ne demandez pas le principe de la POO. Vous en saurez plus à ce sujet dans Programmation orientée objet: le mauvais chemin? étaient Joe Armstrong est cité:

J'ai commencé à me demander quelle était la programmation orientée objet et je pensais que Erlang n'était pas orienté objet, c'était un langage de programmation fonctionnel. Ensuite, mon directeur de thèse a déclaré: "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 tout à fait sûr d’y croire ou non, mais Erlang est peut-être le seul langage orienté objet, car les 3 principes de la programmation orientée objet sont fondés sur la transmission de messages , l’ isolement entre les objets et avoir polymorphisme .

La transmission asynchrone des messages, comme dans les systèmes événementiels et dans Erlang, est également un très bon moyen de découpler les systèmes et le couplage faible 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: Architecture axée sur les événements de domaine

Cependant, je pense que la majeure partie de la réutilisation du code se fait en utilisant des bibliothèques et des frameworks.

L’humble pipe Unix a fait plus pour la réutilisation du code que tout ce qui a été fait. Les objets se sont avérés être un moyen intuitif de structurer le code quand ils sont arrivés, et plus tard, les gens ont commencé à utiliser n'importe quoi dessus. 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 substitut médiocre à ce que devrait être un mécanisme de réutilisation de code.

OOP n'est pas spécial; 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)entrer un nombre et en donner un. Pas de POO, mais certainement plus réutilisable que la plupart des codes existants.

Du point de vue de la programmation fonctionnelle, la programmation orientée objet concerne principalement la gestion des états.

En programmation fonctionnelle, vous pouvez facilement disposer de 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 de petite taille.

Malheureusement, au lieu de (ré) utiliser de nombreuses petites fonctions, certaines personnes dupliquent des fonctionnalités. Pour moi, c'est parce que la POO n'encourage pas la réutilisation de code autant que la programmation fonctionnelle.

Pour moi, oui, mais pas tout le temps, et cela aurait pu être fait autrement.

La plupart du temps, vous créez une classe de base abstraite et créez des implémentations concrètes de cette classe.

De plus, de nombreux frameworks utilisent l'héritage pour permettre la réutilisation du code (Delphi, Java, .Net en sont quelques-uns qui viennent immédiatement à l'esprit).

Cela ne veut pas dire que beaucoup de bibliothèques d'utilitaires et d'extraits de code n'auraient pas pu faire le travail aussi, mais il y a quelque chose d'agréable à propos d'une hiérarchie d'objets bien conçue.

D'après mon expérience, j'ai plus de succès à exploiter le code "réutilisable" via des fonctions de programmation génériques (telles que les modèles C ++) que l'utilisation de principes de POO tels que 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ée une nouvelle instance de moi!" , chaque méthode publique dit: "appelle-moi!" , chaque méthode protégée donne: "écrasez-moi!" - et tous ces modes de réutilisation sont différents , ils ont des paramètres différents, ils apparaissent dans un contexte différent, ils ont tous des règles différentes, comment l'appeler / l'étendre / le remplacer.

L'API est préférable, c'est un sous-ensemble strict de points OOP (ou non-oop), mais dans la vraie vie, les API sont sur-exploitées et en croissance constante, il y a encore trop de points de connexion. En outre, une bonne API peut rendre la vie plus facile, 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 types de ports suivants:

• les consommateurs (intrants), et
• producteurs (sorties).

Dépend du domaine, il y a certains types de paquets, afin que les consommateurs et les producteurs puissent être connectés s'ils ont les mêmes ports (ou compatibles). La plus belle partie de ce qui peut être fait visuellement, parce qu’il n’ya pas de paramètres ni d’autres réglages sur les connexions, elles ne font que connecter un consommateur et un producteur.

J'étais un peu incertain, vous pouvez jeter un oeil sur la balise "dataflow" de StackOverflow , ou sur la "programmation datafow" de Wikipedia ou sur la "programmation basée sur les flux" de Wikipedia .

(En outre, j'ai écrit un système de flux de données, en C ++. Ainsi, OOP et DF ne sont pas des ennemis, DF est un moyen d'organisation de niveau supérieur.)

Dans CommonLisp, il existe de nombreux moyens de réutiliser:

• typage dynamique, votre code étant générique par défaut

• abstractions impératives, c.-à-d. sous-programmes

• orientation objet, avec héritage multiple et envoi multiple

• syntaxe-abstraction, capacité à définir de nouvelles constructions syntaxiques ou à abréger le code de la plaque de chaudière

• Abstractions fonctionnelles, fermetures et fonctions d'ordre élevé

Si vous essayez de comparer l'expérience CommonLisp à d'autres langues, vous constaterez que la principale caractéristique qui facilite la réutilisation du code est la présence d' abstractions à la fois orientées objet et fonctionnelles. Ils sont plus complémentaires qu’alternatifs: sans l’un d’entre eux, vous êtes obligé de réimplémenter les fonctionnalités manquantes de manière maladroite. Voir, par exemple, les classes de foncteur utilisées comme fermetures et correspondance de modèles pour obtenir une répartition de méthode non extensible.

Il n’existe vraiment pas de "réutilisation" de la façon dont les gens le décrivent. La réutilisation est une propriété accidentelle de n'importe quoi. C'est difficile à planifier. Ce que la plupart des gens veulent dire quand ils parlent de "réutilisation", c'est "d'utilisation". C'est un terme beaucoup moins attrayant et passionnant. Lorsque vous utilisez une bibliothèque, vous l'utilisez normalement pour ce à quoi elle était destinée. Vous ne le réutilisez pas sauf si vous faites 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 original. [...] Demain, je vais rentrer au Royaume-Uni. Je ne vais pas réutiliser l'avion. Je vais juste l'utiliser pour le but pour lequel il était destiné, il n'y a rien d'extraordinaire à cela.

- Kevlin Henney

Je vais risquer de ridiculiser et d’avouer que je n’utilise la POO que très récemment. Cela ne me vient pas automatiquement. La plupart de mes expériences concernent des bases de données relationnelles, je pense donc aux tables et aux jointures. Certains prétendent qu'il vaut mieux l'apprendre dès le début, ce qui évite de devoir reformuler ses idées en matière de programmation. Je n’ai pas ce luxe et je refuse d’abandonner ma carrière au détriment d’une théorie de la tour d’ivoire. Comme tout le reste, je vais comprendre.

Au début, je pensais que le concept n’avait aucun sens. Cela semblait juste inutile et trop de problèmes. 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 de code nécessite une volonté de ne pas répéter le code, une compréhension de la manière de le réaliser, une planification initiale. Devez-vous éviter de réutiliser du code une fois que vous avez décidé de ne pas en valoir la peine? Et aucune langue n’est tellement stricte qu’elle génère une erreur quand elle pense que vous devriez hériter 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 la programmation orientée objet est l'acceptation générale de la manière dont le code devrait être organisé. Tout le reste est de la sauce. Une équipe de programmeurs peut ne pas être totalement d'accord sur la structure de toutes les classes, mais elle devrait pouvoir trouver le code.

J'ai vu suffisamment de code de procédure pour savoir que cela pourrait être n'importe où, et parfois c'est partout.

La POO vous donne plus de moyens de réutiliser le code. C'est tout.

Réutilisation horizontale: aspects, traits, greffes

Classic OO ne parvient parfois pas à réutiliser le code, en particulier lorsque vous êtes fous 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 AOP, traits et greffes.

Programmation Orientée Aspect

Je considère AOP comme la demi-orange manquante de OOP. AOP n'est pas vraiment connu, mais il a été transformé en code de production.

Je vais essayer d'expliquer en termes simples: imaginez que vous pouvez injecter et la fonctionnalité de filtre avec une structure spéciale appelée un aspect, ces aspects ont des « méthodes » qui définissent quoi et comment va être affectée par la réflexion , mais au moment de la compilation , ce processus s'appelle le tissage .

Un exemple serait un aspect qui indique "pour toutes les méthodes de certaines classes qui commencent par get, votre programme écrit dans un fichier journal les données obtenues et l'heure à laquelle elles ont été obtenues".

Regardez ces deux entretiens si vous voulez mieux comprendre AOP:

• Utilisation de la programmation orientée aspect pour prévenir les attaques d'applications 1/6
• Programmation orientée aspect: recherche radicale dans la modularité de Gregor Kiczales (l'homme principal derrière AOP)

Traits et greffes

Les traits sont une autre construction permettant de 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 existe un excellent RFC PHP qui explique les deux . Les traits viennent à PHP btw, ils sont déjà commis au coffre.

En résumé

La programmation orientée objet est la clé de la modularité mais, à mon avis, et telle que nous la connaissons aujourd'hui, la programmation orientée objet est encore incomplète .

OOP Fournit un ensemble d'outils utiles vous permettant d'écrire du code pouvant être utilisé dans plus d'endroits que vous ne pourriez en avoir sans ces outils. Si vous écrivez une PrintItfonction qui prend n'importe quel ancien objet et appelle .toString()dessus, vous aurez réutilisé ce code dès que vous l'appelez 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 chez les hipsters. Il vous fournit un ensemble d'outils distincts pour que chaque ligne de code en fasse plus. Ce n'est probablement pas mieux ou ne fonctionne pas, mais fournit un autre outil dans la boîte à outils.

(Il y avait une idée folle pour un niveau supplémentaire de réutilisation orientée objet: l’idée était de pouvoir définir une Customerclasse unique et de l’utiliser dans toutes les applications que nous écrivions. Les applications seraient alors un peu collées ici et là. Cela ne signifie pas pour autant que OO a échoué ou même que la réutilisation a échoué. Les types de base de code réutilisés dans les applications ont permis d’écrire des applications qui en faisaient plus et de les écrire plus rapidement.)

En lisant les articles ci-dessus, quelques remarques:

• Beaucoup pensent que la réutilisation de code en POO implique un héritage. Je ne suis pas d'accord. Les interfaces et les contrats sont au cœur de la réutilisation du code dans les systèmes OOP. OOP est une tentative de boîte grise dans la création d'une technologie de composant.
• La différence entre les "cadres" spécifiques à un domaine et génériques en tant que sujet de réutilisation me semble trop abstraite. À mon avis, un composant (un contrat d’interface concis, minimal et réutilisable et la mise en œuvre sous-jacente) ne peut être réalisé que si le problème qu’il aborde est bien compris. Un composant spécifique à un domaine, qui permet aux experts n'appartenant pas au domaine de faire leur travail avec moins de connaissances sur le domaine, est un composant (re-) utile. Les utilisateurs ont besoin de comprendre l'interface, moins les complexités du domaine problématique.
• Les niveaux de réutilisation sont 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 tests. La réutilisation du code n'est pas toujours favorable. Cependant, il est souvent très avantageux de s'en tenir à une architecture spécifique pour s'attaquer à un nouveau produit similaire.
• Les schémas de conception de la POO (Gamma et al.) Ont à mon sens développé des techniques de mise en œuvre tactiques plutôt que de sens dans le contexte de la réutilisation de code à plus grande échelle. Ils aident à écrire une application avec des éléments POO, mais je ne les verrais pas comme une solution à la question de la "réutilisation du code" au-delà d'une application unique.
• Peut-être que ce n’est pas juste: 20 ans d’expérience C / C ++ / C # et 6 mois de programmation fonctionnelle (F #). Un élément majeur de la réutilisation est le suivant: les utilisateurs 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 à une réutilisation ou le début et la fin. Le "sucre syntaxique" tant prisé est souvent du sel à mes yeux, m'empêchant de voir facilement ce qui se passe. Ainsi, j'essaierais moins de réutiliser une fonction (qu'est-ce que c'est - 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 me semblent douteuses.
• La spécification, la conception, la mise en œuvre sont couplées, mais pas facilement traversables vues sur "la même chose". L’augmentation de la productivité future est bien plus vitale qu’un nouveau paradigme de programmation: combler les lacunes, accroître (raisonnement automatisé, traçabilité) les avantages mutuels entre ces vues. Les langages de spécification formalisés, les notations de test normalisées (par exemple, ttcn3) et les langages de programmation prenant en charge la vérification des interfaces et les contrats par rapport aux spécifications sans commentaire, pourraient constituer notre besoin le plus urgent.

Le problème est plus subtile à mon humble avis:

1. OOP est une excellente méthode pour structurer du code avec un état mutable . En encapsulant l’état dans des objets, le code d’état impératif devient plus compréhensible car, par exemple, si un élément d’État est exprimé en tant que champs privés d’une classe, vous savez qu'au moins cet élément d’état particulier ne peut être modifié que par des méthodes de ce type. classe. (Et vous pouvez facilement casser cet avantage en abusant de l'héritage, au fait.) C'est maintenant assez, mais mieux vaut ne pas l'avoir.
2. le code avec l'état mutable est intrinsèquement difficile à réutiliser . Bien plus difficile que le code utilisant des structures de données immuables.

Ainsi, la programmation orientée objet en soi n’est pas une mauvaise chose de créer du code réutilisable , mais les types de code écrits à l’aide de la programmation orientée objet sont, par nature, difficiles à réutiliser .

En outre, la programmation fonctionnelle peut générer davantage de code réutilisable . Cependant, obtenir les bonnes abstractions pour écrire un code fonctionnel sain tout en respectant une date limite peut ne pas être faisable. Et les abstractions "à moitié droite" seront plus faciles à exprimer en style POO. Et cela ne facilitera pas la réutilisation du code . Un niveau d'abstraction plus élevé signifie que la compréhension du code nécessitera un investissement initial plus important de la part des capacités cognitives limitées des programmeurs.

Comme exemple pratique: Le code de jeu implique beaucoup d’états mutables, car c’est la façon naturelle de penser à coder un jeu. Sauf s’il s’agit d’un casse-tête / d’un algorithme, il est évident qu’il finit par être structuré à l’aide de 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 la POO . Et réécrire pour devenir un style fonctionnel peut nécessiter une modification totale de la façon dont vous envisagez ce code, les connaissances qui le sous-tendent. Ouais, les connaissances acquises derrière le code seraient beaucoup plus claires après la réécriture d'OO à FP ... peut-être, mais le coût pourrait être énorme et ce pourrait êtrele genre de coûts que devraient également payer les personnes qui souhaitent réutiliser le code incroyablement intelligent et bien abstrait que vous obtenez , si paradoxalement que les gens finiraient par ne pas réutiliser le code, même s'il est techniquement plus réutilisable.

... ce qui mène à la dernière subtilité: la réutilisation du code concerne l' interface People | Code , pas seulement le code. OOP fait un travail décent en servant cette interface car elle correspond bien au nombre de personnes qui pensent à de nombreux types de code écrits de nos jours. La PF pourrait être préférable pour la réutilisation du code, mais pas pour le type de code que les gens ont réellement besoin d'écrire de nos jours. Cela changera en tant que type de code dont nous avons besoin pour écrire les modifications.

PS Et si quelqu'un veut dire que "OO ne concerne pas l'état mutable, vous pouvez également avoir OO avec un état immuable" ... J'appelle cela "FP utilisant des classes comme espaces de noms". C’est génial lorsque cela fonctionne pour vous, cela évite certaines lacunes des systèmes de modules de certaines langues et peut générer davantage de code réutilisable. Mais ce n'est pas OO;)