POO ne remplit la promesse de la réutilisation de code? Quelles sont les alternatives pour atteindre la réutilisation de code?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/7618

Question

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

réutilisation de code Est-ce que POO définit, faire des projets plus productifs?

Ou plus facile à gérer? Ou plus facile à entretenir? Ou avec plus de qualité?

Probablement nous sommes tous d'accord que la réutilisation de code est une bonne chose, mais il y a plusieurs façons d'atteindre cet objectif. La question concerne la méthode de réutilisation de code offert par POO. Était-ce une bonne chose? Y at-il de meilleures méthodes de réutilisation de code atteint que l'orientation de l'objet, sous-classage, polymorphisme, etc.? Quels moyens sont mieux? Pourquoi ?

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

Était-ce utile?

La solution

réutilisation de code est une assez bonne idée. Pas un grand .

J'ai une perspective tirée d'environ 30 ans de génie logiciel, en essayant de « réutilisation ».

J'ai commencé à enquêter sur « la réutilisation de code » comme retour de 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 OS que je construit fin des années 70.

La bonne partie de la réutilisation du code est la capacité de réutilisation parfois honnête à dieu le code pré-existante. Mais le monde est complet de code; comment peut trouver ce que vous voulez? Voici ce que j'appelle Malédiction 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 avoir l'un d'eux.

Bon choix de chance.

Pour résoudre bien le problème de la réutilisation:

  • les besoins de Reuser à préciser en quelque sorte ce dont il a besoin (functionaly, performance, langue cible, les 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 choisir les éléments candidats (à un milliard d'éléments, vous ne pouvez pas regarder tous personnellement)
  • il doit être un moyen de Caractérisateur à quelle distance de la spécification des candidats retenus sont
  • un processus régulier devrait exister pour permettre au recycleur de modifier le code réutilisable choisi (Voici la plus grande contribution de la POO. Vous pouvez modifier un composant existant / objet en remplaçant ses emplacements POO ne fournit aucune autre aide).
  • tout cela doit être clairement moins cher que recodage simplement

La plupart du temps ce qui a été découvert au fil des ans est que pour le code soit réutilisable, il sorte de doit être prévu à cet effet, ou il contient trop d'hypothèses implicites. Le plus grand succès des bibliothèques de réutilisation de code ont été effectivement assez petit. bibliothèques et cadres sont sans doute le code « réutilisables », et ils ont beaucoup de succès; Java et C # réussissent pas parce qu'ils sont assez bons langages informatiques, mais plutôt parce qu'ils ont d'énormes bien conçus, mis en œuvre et les bibliothèques documentées disponibles. Mais les gens ne regardent pas le code source dans les bibliothèques; ils appellent simplement une API bien documenté (conçu pour être généralement utilisable).

Qu'est-ce que la réutilisation de code n'a pas fait (POO ni) est de fournir des ordres d'amélioration de l'ampleur dans notre capacité à des systèmes de code.

Je pense que le principal défaut est que tout type de réutilisation de code est fondamentalement limité parce que le code a trop d'hypothèses construites dans . Si vous faites le code minuscule, vous minimisez les hypothèses, mais le coût pour construire à partir de zéro est pas très grand et les gains de réutilisation ne sont pas efficaces. Si vous faites des morceaux de code énorme, ils sont à peu près inutile dans un nouveau contexte. Comme Gulliver, ils sont liés à la plage par un million de chaînes minuscules, et vous ne pouvez tout simplement pas se permettre de les couper tous.

Ce que nous devrions travailler sur réutilisation des connaissances au code de construction . Si nous pouvons faire cela, nous pouvons appliquer ces connaissances au code de construction que nous avons besoin, le traitement de l'ensemble des hypothèses actuelles.

Pour ce faire, on a encore besoin de la même capacité de spécification des composants du logiciel caractérisent (il vous reste à dire ce que vous voulez!). Mais vous appliquez cette connaissance « construction » aux spécifications à générer le code que vous voulez.

En tant que communauté, nous ne sommes pas très bien à ce moment. Mais les gens le font tout le temps; pourquoi ne pouvons-nous automatiser? Il y a beaucoup de recherche, ce qui montre qu'il peut être fait dans de nombreuses circonstances.

Un élément clé de machines nécessaires à cet effet sont des outils mécaniques pour accepter « les descriptions des composants » (ce ne sont que des documents officiels et peuvent être analysés comme des langages de programmation) et appliquer transformations du programme pour eux.

Compilateurs font déjà: -} And ils sont vraiment bons à la classe de problème qu'ils abordent.

modèles UML avec génération de code sont une tentative de le 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 ressemble à ceci ». Assez difficile de générer un véritable programme si la fonctionnalité est laissé.

Je suis en train de construire , un outil appelé DMS . Assez bien distrait été en appliquant des transformations du programme non pas tant aux spécifications abstraites pour générer le code, mais plutôt de code existant pour le nettoyer. (Ce sont le même problème dans l'abstrait!). (Pour construire ces outils prend beaucoup de temps, je fais ça depuis 15 ans et dans le même temps vous devez manger).

Mais DMS a les deux principales propriétés décrites plus haut: la capacité de traiter les spécifications formelles arbitraires, et la capacité de capture « connaissances de génération de code » comme les transformations et les appliquer à la demande. Et remarquablement, nous ne générons dans certains cas particuliers, un code plutôt intéressant des spécifications; DMS est construit en grande partie elle-même en utilisant pour générer sa mise en œuvre. Cela a réalisé pour nous au moins une partie de la promesse de (connaissances) réutilisation: 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 ont une certaine 10MSLOC du code généré.

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

Autres conseils

Code de réutilisation est réalisée en POO, mais il est également réalisé dans la programmation fonctionnelle. Chaque fois que vous prenez un bloc de code et rendre le reste appelable de votre code tel que vous pouvez utiliser cette fonctionnalité est d'ailleurs le code de réutilisation.

Ce type de code réutilisation rend également le code plus facile à gérer, car la modification de ce un bloc appelable change tous les lieux qu'il est appelé. Je dirais que ce résultat une meilleure qualité aussi et la lisibilité.

Je ne suis pas sûr OOP est simplement là pour fournir la réutilisation du code. Je regarde POO comme plus d'une façon d'interagir avec les objets et abstraire les détails de la structure de données.

De Wikpedia:

La programmation orientée objet a des racines qui remontent aux années 1960. Comme le matériel et les logiciels sont devenus, de gestion de plus en plus complexe devient souvent une préoccupation. Les chercheurs ont étudié les moyens de maintenir la qualité des logiciels et développé la programmation orientée objet en partie pour répondre aux problèmes communs en mettant l'accent fortement discret, les unités réutilisables de la logique de programmation [citation nécessaire]. La technologie se concentre sur les données plutôt que des processus, avec des programmes composés de modules autonomes ( « classes »), chaque instance dont ( « objets ») contient toutes les informations nécessaires pour manipuler sa propre structure de données ( « membres »). Ceci est en contraste avec la programmation modulaire existant qui avait été dominante depuis de nombreuses années qui mettait l'accent sur la fonction d'un module, plutôt que spécifiquement les données, mais également prévue pour la réutilisation du code et des unités réutilisables autonomes de la logique de programmation, permettant la collaboration par l'utilisation des modules liés (sous-programmes). Cette approche plus conventionnelle, qui persiste encore, a tendance à considérer les données et les comportements séparément.

Oui et Non

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

  1. réutilisation du code dans un seul projet. OO est parfaitement adapté pour cela, une application bien conçue aura cartographié les relations du étroitement monde modélisé, ce qui élimine la duplication de code, autant que possible et souhaitable . Cependant, vous pouvez faire valoir que les technologies pré-OO pourrait réaliser la même chose, ce qui est vrai, mais OO est à bien des égards plus pratique.
  2. bibliothèques de tiers Cela semble fonctionner aussi bien avec ou sans OO.
  3. Code Cross-but la réutilisation La plus grande promesse réutilisation de code OO était ce code, une fois écrit pour une application peut ensuite être réutilisée pour une autre, qu'il n'a pas été spécialement conçu pour. Ce fut toute la rage lorsque la notion de OO filtrée à travers les portes des bureaux de gestion plus élevés, et OO complètement échoué pour y parvenir. Il est avéré que but était un aspect crucial de la conception orientée objet (et peut-être tout le code de procédure, mais qui est seulement ma théorie) et des tentatives de code de repurposing terminé en cas de catastrophe d'entretien. (Le bien connu antipatternsof un vieux DARES personne ne cadre de modifier et de son ami, les légèrement différents-cadres-pour-chaque-app découlent généralement d'ici.)

Je posterais une longue réponse, mais pourquoi? Udi Dahan explique bien mieux que je peux.

http://www.udidahan.com/2009/06/07/ l'erreur-de-réutilisation /

Voici le début du message:

Cette industrie est pré-occupé par réutilisation.

Il y a cette croyance que si nous venons plus de code réutilisé, tout serait mieux.

Certains vont même jusqu'à dire que le point entier de l'orientation objet était réutilisation - il n'a pas été, l'encapsulation était la grande chose. Après ça composante orientation était la chose qui était censé faire la réutilisation se produire. Apparemment, cela n'a pas marché si bien soit parce qu'ici nous sommes maintenant épingler nos espoirs sur reuseful service d'orientation.

Des livres entiers de modèles ont été écrit sur la façon de parvenir à la réutilisation avec l'orientation de la journée. Prestations de service ont été classés dans tous les sens en essayant d'y parvenir, de l'entité services et services d'activités, grâce à des services de traitement et services d'orchestration. Composition services a été présentée comme la clé la réutilisation et la création réutilisable services.

je pourrais aussi bien vous laisser sur la secret peu sale:

La réutilisation est une erreur

Je suis d'accord avec Chris, la programmation fonctionnelle est un bon moyen de code de réutilisation.

De nombreux programmes a des structures de code qui est récurrent. Pour cela une design patterns sont utilisés dans le monde POO, mais cela peut être réalisé par fonctions récursives et correspondant modèle dans les langages de programmation fonctionnelle. Pour en savoir plus sur ce sujet, voir le premier chapitre monde réel fonctionnel de programmation.

Je pense que l'héritage profond POO peut être trompeur dans de nombreux cas. Vous avez une classe et la plupart des méthodes étroitement liées sont mises en œuvre dans différents fichiers. Comme Joe Armstrong dit au sujet de la POO:

Le problème avec les langages orientés objet est qu'ils ont tout cet environnement implicite qu'ils portent avec eux. Vous vouliez une banane, mais ce que tu as était un gorille tenant la banane et la jungle entière.

hautes fonctions de commande sont également très utiles en matière de réutilisation de code par exemple map et foldr qui est la base de Google MapReduce .

messages asynchrones est aussi un bon moyen pour organiser des logiciels complexes, et un état de chercheurs en informatique que les objets ont été supposés communiquer avec eachother asynchrone comme dans le Tell, ne demande pas principe POO. Voir plus à ce sujet dans Programmation Orientée Objet: Le mauvais chemin étaient Joe Armstrong est cité:

Je posais des questions sur ce que la programmation orientée objet était et je pensais que Erlang n'a pas été orienté objet, il est un langage de programmation fonctionnelle. Ensuite, mon directeur de thèse a dit: « Mais vous avez tort, Erlang est un objet extrêmement orienté ». Il a dit des langages orientés objet sont pas orienté objet. Je pourrais penser, bien que je ne suis pas tout à fait sûr si je crois ou non, mais Erlang peut-être la seule langue orientée objet parce que les 3 principes de la programmation orientée objet est qu'il est basé sur un message passe , que vous avez isolement entre les objets et ont polymorphisme .

messages asynchrones comme dans les systèmes événementielles et Erlang est aussi un très bon moyen de systèmes de couplage et DECOUPLE lâche est important dans les systèmes complexes. Avec un système suffisamment découplé vous pouvez évoluer le système en cours d'exécution, peut-être sur les différents nœuds. Unibet fait une belle présentation à ce sujet: domaine Driven Architecture

Cependant, je pense que la plupart de la réutilisation de code se fait à l'aide des bibliothèques et des cadres.

La conduite unix humble a fait plus pour la réutilisation de code que toute autre chose qui est venu et reparti. Les objets se trouvait être un moyen intuitif de code structurant quand ils sont arrivés et les gens plus tard commencé à virer sur quoi que ce soit et tout sur elle. Dans les objets généraux sont pour l'encapsulation et non pour la réutilisation du code, la réutilisation du code exige quelque chose de plus et la hiérarchie de l'héritage de classe est un pauvre substitut à ce qui devrait vraiment être un mécanisme de réutilisation de code.

OOP est pas spécial; vous pouvez faire du code réutilisable avec ou sans POO. Fonctions pures sont particulièrement réutilisables : par exemple, java.lang.math.sqrt(double) prend un certain nombre et donne un numéro sur. Non POO, mais certainement plus réutilisable que la plupart du code là-bas.

Du point de vue de la programmation fonctionnelle POO est la plupart du temps sur la gestion de l'Etat.

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 liste de classe? Méthodes publiques sont considérées comme une interface à l'état interne que vous voulez garder les petits.

Malheureusement, au lieu de (re) en utilisant beaucoup de petites fonctions, certaines personnes fonctionnalité double. Pour moi, c'est parce que POO ne favorise pas le code réutilisation autant que la programmation fonctionnelle fait.

Pour moi, oui, mais pas tout le temps, et il aurait pu faire d'autres moyens.

La plupart du temps en créant une classe de base abstraite et la création d'implémentations concrètes de cette catégorie.

En outre, beaucoup de cadres par l'héritage pour fournir la réutilisation de code (Delphi, Java, .Net sont quelques-unes que le printemps instantanément à l'esprit).

Ce ne veut pas dire que beaucoup de bibliothèques de services publics et des extraits de code ne pouvait pas avoir fait le travail aussi bien, mais il est agréable de quelque chose sur une hiérarchie d'objets bien conçu.

Dans mon expérience, j'ai levier financier code « réutilisable » plus de succès grâce à des installations de programmation génériques (comme C ++ modèles) que je l'ai eu en utilisant les principes de la POO comme des hiérarchies d'héritage.

POO est trop ouvert pour une réutilisation efficace.

Il y a trop de façons de réutiliser. Chaque classe publique demande: "! Faire une nouvelle instance de moi" , chaque méthode publique dit: "appelez-moi!" , le rendement de chaque méthode protégée: "override moi " - et tous ces moyens de réutilisation sont différents , ils ont des paramètres différents, ils apparaît dans un contexte différent, ont toutes leurs règles différentes, comment appeler / étendre / remplacer.

API est meilleur, il est un sous-ensemble strict de points POO (ou non-oop), mais dans la vie réelle, les API sont overfeatured et croissance pour toujours, il sont encore trop de points de connexion . En outre, une bonne API peut rendre la vie plus facile, il est la meilleure façon de fournir une interface pour POO.

Datadlow paradigme fournit une interface stricte pour les composants, ils ont des ports de types suivants:

  • consommateurs (entrées), et
  • producteurs (sorties).

dépend du domaine, il sont certains types de paquets, afin que les consommateurs et les producteurs peuvent, ils être connectés ont des ports mêmes (ou compatibles). La plus belle partie, qu'il peut faire visuellement, parce qu'il n'y a pas de paramètres ou sommes tweaks orher sur les connexions, ils se connecte vraiment juste un consommateur et un producteur.

J'étais un peu clair, vous pouvez jeter un oeil sur "flux de données" tag sur StackOverflow ou Wikipedia "datafow programmation" ou Wikipedia " de programmation basée sur les flux".

(, je l'ai aussi écrit un système de flux de données, en C ++. Alors POO et DF ne sont pas ennemis, DF est un moyen d'organisation de niveau supérieur.)

Dans CommonLisp il y a beaucoup de moyens pour y parvenir réutilisation:

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

  • abstractions impératifs, à savoir les sous-routines

  • -orientation de l'objet, avec l'héritage multiple et multiple envoi

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

  • abstractions fonctionnelles, la fermeture et l'ordre de haut fonctions

Si vous essayez de comparer l'expérience CommonLisp à d'autres langues, vous verrez que la principale caractéristique que la réutilisation Soulage de code est la présence de à la fois orientées objet et abstractions fonctionnelles. Ils sont plus complémentaires que solution de rechange: sans un d'entre eux, vous êtes obligé de ré-écrire les fonctionnalités manquantes d'une manière maladroite. Voir, par exemple, les classes de foncteurs utilisées comme fermetures et correspondance de motif pour obtenir l'envoi de méthode non extensible.

Il n'y a vraiment pas une telle chose comme « réutilisation » de la façon dont les gens le décrivent. La réutilisation est une accidentelle de quoi que ce soit. Il est difficile de planifier. Ce que la plupart des gens veulent dire quand ils parlent de « réutilisation » est « l'utilisation ». Il est un terme beaucoup moins attrayant et passionnant. Lorsque vous utilisez une bibliothèque, vous utilisez pour ce qu'il était destiné, normalement. Vous êtes pas réutiliser à moins que vous faites quelque chose de vraiment fou avec elle.

Dans ce sens, la réutilisation dans le monde réel est des choses ré-purposing. 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 principale utilisation. Je les réutilisez en dehors de leur domaine d'application d'origine. [...] Demain, je vais rentrer au Royaume-Uni. Je pas réutiliser l'avion. Je vais l'utiliser dans le but il était destiné, il n'y a rien d'extraordinaire ou excitant à ce sujet.

- Kevlin Henney

Je vais le ridicule des risques et confessent, je ne l'ai été en utilisant OOP très récemment. Il ne me vient pas automatiquement. La plupart de mon expérience implique des bases de données relationnelles, donc je pense que dans les tableaux et les joints. On prétend qu'il est préférable d'apprendre dès le début qui évite d'avoir à recâbler votre pensée en matière de programmation. Je n'ai pas ce luxe et refuse d'abandonner ma carrière sur une théorie de la tour d'ivoire. Comme tout le reste, je vais comprendre.

Dans un premier temps je pensais que le concept n'a pas de sens. Il semblait juste des ennuis inutiles et trop. Je sais, ce fou parle. De toute évidence, il faut un certain niveau de compréhension avant de pouvoir apprécier les avantages de tout ou rejeter de meilleures méthodes.

réutilisation de code prend une volonté de code ne le répète, une compréhension de la façon de l'accomplir, la planification initiale. Si vous évitez de réutiliser le code lorsque vous avez décidé que vous avez un cas où il est tout simplement pas la peine? Et aucune langue est si strictement OO qu'il lancera une erreur quand il pense que vous devriez avoir un code hérité d'une autre classe. Au mieux, ils offrent un environnement propice à la mise en œuvre.

Je pense que le plus grand avantage de la POO est l'acceptation générale de la manière d'organiser le code. Tout le reste de la sauce. Une équipe de programmeurs ne peut pas entièrement d'accord sur la façon dont toutes les classes doivent être structurées, mais ils devraient être en mesure de trouver le code.

J'ai vu assez de code de procédure pour savoir qu'il pourrait être partout, et parfois il est partout.

POO vous donne plus moyens de code de réutilisation. C'est tout.

réutilisation horizontale: aspects, traits, greffes

classique OO tombe parfois court sur la réutilisation de code, spécialement quand vous allez tout l'héritage fou faute d'une meilleure façon de partager la fonctionnalité réelle entre les classes. Pour ce problème, les mécanismes de réutilisation horizontaux ont été créés, comme AOP, des traits et des greffes.

Programmation Orientée Aspect

Je considère comme AOP disparus demi-orange POO. AOP n'est pas vraiment connu, mais il a fait le 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 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 obtenir, vous allez écrire le programme dans un fichier journal les données qui ont été obtenu et le temps était obtenir ».

Regardez ces deux discussions si vous voulez mieux comprendre AOP:

& Greffes caractères

Traits sont une autre construction pour définir un code réutilisable qui OOP complément, ils sont similaire à mixins , mais plus propre.

Plutôt que de les expliquer, il y a un grand PHP RFC qui explique à la fois . Viennent à caractères PHP BTW, ils sont déjà engagés à tronc.

En résumé

POO est la clé de la modularité, encore, à mon avis et comme nous le savons souvent aujourd'hui POO est encore incomplète .

POO Fournit un ensemble d'outils utiles qui vous permettent d'écrire du code qui peut être utilisé dans plus d'endroits que vous pourriez avoir sans ces outils. Si vous écrivez une fonction PrintIt qui prend un objet quelconque et appelle .toString() là-dessus, vous devrez re-utiliser ce code dès que vous l'appelez avec plus d'un type d'objet. Avec ces outils, chaque ligne de code fait plus.

La programmation fonctionnelle est très chaud en ce moment parmi les hipsters. Il vous offre une tout distinct un ensemble d'outils pour chaque ligne de code en faire plus. Il est sans doute pas le meilleur ou des œuvres, mais fournit un autre outil dans la boîte à outils.

(Il y avait une idée folle pour un niveau supplémentaire toute réutilisation orientée objet. L'idée était que nous pourrions définir une classe unique Customer et l'utiliser dans toutes les applications que nous avons écrit des applications serait alors juste un peu de colle ici et là. Cela n'a pas marché. Mais cela ne signifie pas que l'OO a échoué, ou même que la réutilisation a échoué. les types de code de réutilisation dans les applications ont permis d'écrire des applications qui ont fait plus, et de les écrire plus rapide.)

La lecture des messages ci-dessus, quelques remarques:

  • Beaucoup pensent que la réutilisation de code dans POO implique l'héritage. Je ne suis pas d'accord. Interfaces et contrats sont au cœur de la réutilisation du code dans les systèmes de POO. POO est une boîte grise tentative de création d'une technologie composant.
  • La différence entre de domaine spécifique et « cadres » génériques comme sujet de la réutilisation me jugent trop abstraite. À mon avis sur les choses, un composant (un résumé concis, contrat d'interface minimale et réutilisable et le derrière de la mise en œuvre) ne peut se faire, si le problème qu'il traite est bien compris. Un composant de domaine spécifique, ce qui permet aux experts non domaine de faire leur travail avec moins de connaissances sur le domaine est un (re) composante utile. Les utilisateurs doivent comprendre l'interface, moins les subtilités du domaine du problème.
  • Les niveaux de réutilisation souvent oubliée: Idée réutilisation, réutilisation Spécification, Architecture / Design réutilisation, Interface réutilisation, réutilisation test cas. Code réutilisation est pas toujours favorable. Mais il est un grand gain de temps souvent coller à une architecture spécifique pour lutter contre un nouveau produit similaire.
  • Les motifs de conception POO (Gamma et. Al) à mes yeux élaboré sur les techniques de mise en œuvre tactique plutôt que d'être un sens dans le contexte du code de réutilisation à plus grande échelle. Ils aident à écrire une application avec des éléments de la POO, mais je ne les vois pas comme une solution à la question « code réutilisation » au-delà d'une seule application.
  • Peut-être qu'il est injuste: 20 ans de C / C ++ / C # et expérience 6 mois de programmation fonctionnelle (F #). Un élément important de permettre la réutilisation est: Les gens ont besoin de trouver facilement « l'interface », étudier, comprendre, utilisez-le. programmation fonctionnelle pure ne rend pas facile pour moi de voir la structure, les candidats à la réutilisation ou si tout commence et où tout se termine. La tant vantée « sucre syntaxique » est souvent le sel dans mes yeux, me empêcher de voir facilement ce qui se passe. Thusly Je moins probablement essayer de réutiliser une fonction (ce qui est-il - tas de fonctions?), Ce qui peut avoir des effets secondaires cachés, je ne peux pas voir même (évaluation paresseuse, monades, ...). Ne vous méprenez pas, la programmation fonctionnelle est très cool côtés, mais toutes les forces proclamé que je vois avec une bonne mesure de doute. Je suis très curieux de ce que l'avenir post-fonctionnelle et apporte l'espoir de le voir avant de me retirer;)
  • Spécification, Conception, mise en œuvre sont couplés, mais pas facilement franchissables vues sur la « même chose ». Beaucoup plus vital pour une productivité accrue de l'avenir qu'un nouveau paradigme de programmation est de combler l'écart, pour augmenter (raisonnement automatisé, traçabilité) les avantages mutuels entre ces points de vue. langages de spécification formalisées, les notations d'essai normalisées (par exemple ttcn3) et les langages de programmation supportant la vérification des interfaces et des contrats par rapport aux spécifications sans commentaire déchets sauvages pourraient être ce que nous avons besoin le plus urgent.

Le problème est AMHA plus subtile:

  1. POO est un bonne méthode pour le code de structuration avec l'état mutable . En encapsulant l'état des objets, le code impératif statefull devient plus compréhensible parce que, 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'Etat ne peut être modifié par méthodes de cette classe. (Et vous pouvez facilement briser cet avantage en abusant de l'héritage, btw.) cela suffit maintenant, mais waaay mieux que de ne pas avoir même cela.
  2. Code avec l'état mutable est intrinsèquement difficile à réutiliser . Way plus difficile que le code en utilisant des structures de données immuables.

POO en soi pas mal de pov de faire du code réutilisable , mais le genre de code qui sont écrits en utilisant OOP sont par nature difficiles à réutiliser .

En outre, programmation fonctionnelle peut les résultats dans code plus réutilisable . Mais obtenir les abstractions droit de code fonctionnel écriture sain d'esprit tout en respectant un délai peut ne pas être faisable. Et abstractions « demi-droit » sera plus facile d'exprimer le style POO. Et il ne sera pas tendance à se traduire par plus facile au code de réutilisation -. Niveau supérieur de moyens abstractions que la compréhension du code nécessitera un investissement initial plus élevé de programmeurs capacité cognitive limitée

A titre d'exemple pratique: Code du jeu implique beaucoup de l'état mutable, parce que c'est la façon naturelle de penser à coder un jeu, à moins que c'est un très casse-tête / algorithmique, il finit évidemment en étant structuré en utilisant OO. Et bien sûr, il est difficile de réutiliser. Mais le même code, contenant les mêmes connaissances, serait encore plus difficile à réutiliser sans POO . Et la réécriture à être pourrait de style fonctionnel besoin changer totalement la façon dont vous pensez à ce code, la connaissance derrière. Ouais, le résultat connaissances derrière le code serait beaucoup plus clair après l'OO FP récrire peut-être ... mais le coût pourrait être énorme et il pourrait être le genre de coût qui devrait également être payé par des personnes qui souhaitent réutiliser le incroyablement intelligent et bien le code abstraite vous vous retrouvez avec , si paradoxalement, les gens finissent 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 est sur Les gens | code interface, pas le seul code. POO fait un travail décent au service de 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 la réutilisation du code, mais IMHO pas pour réutiliser facilement le type de code que les gens ont vraiment besoin d'écrire de nos jours. Cela changera comme genre de code que nous avons besoin de modifications d'écriture.

P.S. Et si quelqu'un veut dire que « OO n'est pas sur l'état mutable, vous pouvez aussi avoir OO avec l'état immuable » ... que j'appelle « FP en utilisant des classes comme espaces de noms ». Il est génial quand cela fonctionne pour vous et il évite certaines lacunes des systèmes de modules de certaines langues et peut entraîner un code plus réutilisable. Mais ce n'est pas OO;)

Licencié sous: CC-BY-SA avec attribution
scroll top