Erfüllt OOP das Versprechen der Code -Wiederverwendung? Welche Alternativen gibt es, um eine Wiederverwendung von Code zu erzielen?

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

Frage

Das vielleicht größte Versprechen, objektorientiertes Paradigma zu verwenden, ist die Code-Wiederverwendung. Einige Streitigkeiten, dass dies erreicht wurde. Warum wurde es (nicht) erreicht?

Macht die Wiederverwendung von Code, wenn OOP es definiert, Projekte produktiver?

Oder überschaubarer? Oder leichter zu warten? Oder mit mehr Qualität?

Wahrscheinlich sind wir uns alle einig, dass die Wiederverwendung von Code eine gute Sache ist, aber es gibt verschiedene Möglichkeiten, dieses Ziel zu erreichen. Die Frage bezieht sich auf die von OOP angebotene Code -Wiederverwendung. War es eine gute Sache? Gibt es bessere Methoden zur Wiederverwendung von Code -Wiederverwendung als Objektorientierung, Subklasse, Polymorphismus usw.? Wie sind besser? Warum?

Sagen Sie uns Ihre Erfahrungen mit der OOP -Wiederverwendung oder einer anderen Paradigmen -Wiederverwendung.

War es hilfreich?

Lösung

Die Wiederverwendung von Code ist eine ziemlich gute Idee. Keine großartige.

Ich habe eine Perspektive aus etwa 30 Jahren Software -Engineering, die versucht zu "wiederverwenden".

Ich begann in den 80er Jahren mit der Untersuchung der "Code -Wiederverwendung" als Forschungsthema, nachdem ich festgestellt hatte, dass ich das Design eines Betriebssystems wiederverwendet hatte, das ich Anfang der 70er Jahre für ein weiteres Betriebssystem, das ich Ende der 70er Jahre gebaut habe, gebaut hatte.

Der gute Teil der Wiederverwendung von Code ist die Fähigkeit, ehrlich zugleisen, bereits vorhandener Code wiederzuverwenden. Aber die Welt ist voll von Code; Wie können Sie das finden, was Sie wollen? Folgendes nenne ich das Fluch wiederverwenden:

Ich bin Santa Claus (OK Open Source) und habe eine Tüte mit 1 Milliarde Softwarekomponenten. Sie können jemanden von ihnen haben.

Viel Glück bei der Wahl.

Um das Wiederverwendungsproblem gut zu lösen:

  • Der REUSER muss irgendwie angeben, was er braucht (FunktionALY, Leistung, Zielsprache, Umgebungsannahmen, ...)
  • Es muss eine Bibliothek mit "wiederverwendbarem" Code geben, die auf verschiedene Weise nach diesen potenziellen Kriterien indiziert wurde
  • Es muss ein Mechanismus existieren, um Kandidatenelemente auszuwählen (bei einer Milliarde Elemente können Sie sie nicht alle persönlich betrachten)
  • Es muss eine Möglichkeit geben, zu charakterisieren, wie weit die Spezifikation der ausgewählten Kandidaten entfernt sind
  • Es sollte ein regelmäßiger Prozess vorhanden sein, damit der REUser den ausgewählten wiederverwendbaren Code ändern kann (hier ist der größte Beitrag von OOP: Sie können eine vorhandene Komponente/ein vorhandenes Objekt bearbeiten, indem Sie seine Slots überschreiben. OOP bietet keine andere Hilfe).
  • All dies muss eindeutig billiger sein, als es einfach neu zu erfassen

Meistens, was im Laufe der Jahre entdeckt wurde, ist, dass Code, dass Code wiederverwendbar ist, zu diesem Zweck ausgelegt werden muss, oder es enthält zu viele implizite Annahmen. Die erfolgreichsten Bibliotheken zur Wiederverwendung von Code waren tatsächlich ziemlich klein. Möglicherweise sind Bibliotheken und Frameworks "wiederverwendbarer" Code und sind äußerst erfolgreich. Java und C# gelingt nicht, weil sie ziemlich gute Computersprachen sind, sondern weil sie riesige, gut gestaltete, implementierte und dokumentierte Bibliotheken zur Verfügung haben. Aber die Leute schauen sich den Quellcode in den Bibliotheken nicht an. Sie nennen einfach eine gut dokumentierte API (so konzipiert, dass sie im Allgemeinen verwendet werden kann).

Was die Wiederverwendung von Code noch nicht getan hat (oop auch nicht), ist die Verbesserung der Größenordnungen in unserer Fähigkeit, Systeme zu codieren.

Ich denke, der Schlüsselfehler ist das Jede Art von Code -Wiederverwendung ist grundlegend begrenzt, da Code zu viele Annahmen integriert ist. Wenn Sie den Code winzig machen, minimieren Sie die Annahmen, aber die Kosten für die Erstellung von Grund auf sind nicht sehr groß und die Wiederverwendungsergebnisse sind nicht wirksam. Wenn Sie die Code -Stücke riesig machen, sind sie in einem neuen Kontext ziemlich nutzlos. Wie Gulliver sind sie mit einer Million winziger Saiten an den Strand gebunden, und Sie können es sich einfach nicht leisten, sie alle zu schneiden.

Woran wir arbeiten sollten, ist Wiederverwendung von Wissen zur Konstruktion Code. Wenn wir dies tun können, können wir dieses Wissen anwenden, um Code zu konstruieren, den wir benötigen, und die aktuellen Annahmen abwickeln.

Dazu benötigt man noch die gleiche Spezifikationsfähigkeit, um Softwarekomponenten zu charakterisieren (Sie müssen immer noch sagen, was Sie wollen!). Aber dann wenden Sie dieses "Konstruktionskenntnis" auf die Spezifikationen an generieren der Code, den Sie wollen.

Als Gemeinschaft sind wir noch nicht sehr gut. Aber die Leute machen es die ganze Zeit; Warum können wir es nicht automatisieren? Es gibt viel Forschung, und dies zeigt, dass dies unter vielen Umständen durchgeführt werden kann.

Ein wichtiger Maschinenstück, der dafür benötigt wird, sind mechanische Werkzeuge zum Akzeptieren von "Komponentenbeschreibungen" (dies sind nur formelle Dokumente und können wie Programmiersprachen analysiert werden) und bewerben Programmtransformationen zu ihnen.

Compiler tun dies bereits:-} und sie sind wirklich gut in der Klasse des Problems, die sie angehen.

UML -Modelle mit Codegenerierung sind ein Versuch, dies zu tun. Kein sehr guter Versuch; Ziemlich genau das, was man in den meisten UML -Modellen sagt, ist "Ich habe Daten, die so aussehen". Ziemlich schwer, ein echtes Programm zu generieren, wenn die Funktionalität ausgelassen wird.

Ich versuche zu bauen Praktische Programmtransformationssysteme, ein Tool namens DMS. Wurde ziemlich gut abgelenkt, indem sie Programmtransformationen nicht so sehr auf abstrakte Spezifikationen anwenden, um Code zu generieren, sondern auf Legacy -Code, um ihn zu bereinigen. (Dies sind das gleiche Problem in der Zusammenfassung!). (Um solche Werkzeuge zu erstellen, braucht ich viel Zeit; ich mache das seit 15 Jahren und in der Zwischenzeit muss man essen).

DMS verfügt jedoch über die beiden oben beschriebenen wichtigsten Eigenschaften: die Fähigkeit, willkürliche formale Spezifikationen zu verarbeiten, und die Fähigkeit, "Kenntnisse der Codegenerierung" als Transformationen zu erfassen und sie auf Nachfrage anzuwenden. Und bemerkenswerterweise generieren wir in einigen besonderen Fällen, einem ziemlich interessanten Code aus Spezifikationen; DMS wird größtenteils mit sich selbst erstellt, um seine Implementierung zu generieren. Das hat uns zumindest ein Teil des Versprechens der (Wissen) Wiederverwendung erreicht: äußerst bedeutende Produktivitätsgewinne. Ich habe ein Team von ungefähr 7 technischen Menschen; Wir haben wahrscheinlich 1-2 MSLOC mit "Spezifikationen" für DMS geschrieben, haben jedoch einen generierten Code von 10 ms.

Zusammenfassung: Wiederverwendung des Generationswissens ist der Sieg, nicht Wiederverwendung von Code.

Andere Tipps

Die Wiederverwendung von Code wird in OOP erreicht, aber auch in funktioneller Programmierung erreicht. Jedes Mal, wenn Sie einen Codeblock einnehmen und ihn durch den Rest Ihres Codes aufrufen, sodass Sie diese Funktionalität an anderer Stelle verwenden können, ist die Wiederverwendung von Code.

Diese Art von Code-Wiederverwendung macht Code auch besser verwaltbar, da das Ändern dieses einen Callable-Blocks alle Orte, die er aufgerufen wird, ändert. Ich würde sagen, dass dieses Ergebnis auch die Qualität und die Lesbarkeit erhöhte.

Ich bin mir nicht sicher, ob OOP einfach da ist, um eine Wiederverwendung von Code bereitzustellen. Ich betrachte OOP eher als eine Möglichkeit, mit Objekten zu interagieren und die Details der Datenstruktur abstrahieren.

Von wikpedia:

Objektorientierte Programmierung hat Wurzeln, die auf die 1960er Jahre zurückgeführt werden können. Als Hardware und Software immer komplexer wurden, wurde die Verwaltbarkeit häufig zu einem Problem. Die Forscher untersuchten Wege zur Aufrechterhaltung der Softwarqualität und entwickelte objektorientierte Programmierung zum Teil, um gemeinsame Probleme zu lösen, indem diskrete, wiederverwendbare Programmierlogik festgestellt wurde [Zitat erforderlich]. Die Technologie konzentriert sich eher auf Daten als auf Prozesse, wobei Programme aus autarken Modulen ("Klassen") bestehen, von denen jede Instanz ("Objekte") alle Informationen enthält, die zur Manipulation ihrer eigenen Datenstruktur ("Mitglieder") erforderlich sind. Dies steht im Gegensatz zu der vorhandenen modularen Programmierung, die seit vielen Jahren dominant war und sich auf die Funktion eines Moduls und nicht speziell auf die Daten konzentrierte, jedoch gleichermaßen für die Wiederverwendung von Code und die autarke wiederverwendbare Programmierlogik vorgesehen ist, um die Zusammenarbeit zu ermöglichen durch die Verwendung von verknüpften Modulen (Unterroutinen). Dieser konventionellere Ansatz, der weiterhin anhält, berücksichtigt die Daten und das Verhalten getrennt.

Ja und nein

Die Wiederverwendung von Code ist ein Surme für viele verschiedene Aktivitäten.

  1. Code -Wiederverwendung innerhalb eines einzelnen Projekts. OO ist dafür perfekt geeignet. Eine gut gestaltete Anwendung hat die Beziehungen der modellierten Welt genau zugeordnet, wodurch der doppelte Code so weit wie möglich und ratsam beseitigt wird. Sie können jedoch argumentieren, dass Pre-OO-Technologien dasselbe erreichen könnten, was wahr ist, aber OO ist in vielerlei Hinsicht bequemer.
  2. Bibliotheken Dritter Dies scheint gleich gut mit oder ohne OO zu funktionieren.
  3. Cross-Purple-Code-Wiederverwendung Das größte Code-Rese-Versprechen von OO war, dass Code, das für eine Anwendung geschrieben wurde, später für eine andere wiederverwendet werden kann, für die er nicht speziell entwickelt wurde. Dies war der ganze Wut, wenn der Begriff von OO, die durch die Türen höherer Verwaltungsbüros filtriert wurden, und OO dies völlig nicht erreichte. Es stellte sich heraus, dass dieser Zweck ein entscheidender Aspekt des OO -Designs (und möglicherweise aller Verfahrenscode, aber das ist nur meine Theorie) und Versuche, Code zu wiederholen, endete in Wartungskatastrophen. (Das bekannte Antipatterns von einem alten Rahmen, den niemand wagt, und sein Freund, die leicht differenzierenden Frameworks-for-ty-Apps normalerweise von hier aus.)

Ich würde eine lange Antwort posten, aber warum? Udi Dahan erklärt es viel besser als ich.

http://www.udidahan.com/2009/06/07/the-fallacy-of-rese/

Hier ist der Beginn des Beitrags:

Diese Branche ist mit Wiederverwendung vorbereitet.

Es gibt diese Überzeugung, dass, wenn wir nur mehr Code wiederverwenden würden, alles besser wäre.

Einige gehen sogar so weit, dass der springende Punkt der Objektorientierung die Wiederverwendung war-es war nicht, dass die Kapselung die große Sache war. Danach war die Komponentenorientierung das, was wiederverwenden sollte. Anscheinend hat das auch nicht so gut herausgekommen, weil wir hier jetzt unsere wiederverwendenden Hoffnungen auf Service-Orientierung festlegen.

Ganze Bücher von Mustern wurden über die Wiederverwendung mit der Ausrichtung des Tages geschrieben. Die Dienstleistungen wurden in jeder Hinsicht eingestuft, um dies zu erreichen, von Unternehmensdiensten und Aktivitätsdiensten über Prozessdienste und Orchestrierungsdienste. Das Komponieren von Diensten wurde als Schlüssel zur Wiederverwendung und Erstellung wiederverwendbarer Dienste angepriesen.

Ich könnte Sie genauso gut auf das Geheimnis des schmutzigen Littlittels einlassen:

Wiederverwendung ist ein Irrtum

Ich stimme Chris zu, funktionale Programmierung ist eine gute Möglichkeit, den Code wiederzuverwenden.

Viele Programme haben Codestrukturen, die wiederkommen. Dafür einige Designmuster werden in der OOP-Welt verwendet, dies kann aber durch erreicht werden rekursive Funktionen und Musteranpassung in funktionalen Programmiersprachen. Weitere Informationen finden Sie im ersten Kapitel in Funktionale Programmierung realer Welt.

Ich denke, dass in vielen Fällen eine tiefe Vererbung in OOP irreführend sein kann. Sie haben eine Klasse und viele der eng verwandten Methoden werden in verschiedenen Dateien implementiert. Wie Joe Armstrong sagte über OOP:

Das Problem mit objektorientierten Sprachen ist, dass sie all diese implizite Umgebung haben, die sie mit sich herum tragen. Sie wollten eine Banane, aber was Sie bekommen haben, war eine Gorilla, die die Banane und den gesamten Dschungel hielt.

Funktionen mit hoher Ordnung sind auch sehr nützlich, wenn es um die Wiederverwendung von Code -Wiederverwendung geht, z. map und foldr Das ist die Grundlage für Google's Karte verkleinern.

Asynchrone Nachricht passieren ist auch eine gute Möglichkeit, komplexe Software zu organisieren, und einige Informatiker geben an, dass Objekte miteinander asynchron sind wie in der Sagen Sie, fragen Sie nicht OOP -Prinzip. Sehen Sie mehr darüber Objektorientierte Programmierung: Der falsche Pfad? war Joe Armstrong wird zitiert:

Ich begann mich zu fragen, was objektorientierte Programmierung war, und ich dachte, Erlang sei nicht objektorientiert, sondern eine funktionale Programmiersprache. Dann sagte mein Thesis -Supervisor "Aber Sie liegen falsch, Erlang ist extrem objektorientiert." Er sagte, objektorientierte Sprachen seien nicht objektorientiert. Ich könnte denken, obwohl ich nicht ganz sicher bin, ob ich das glaube oder nicht, aber Erlang ist möglicherweise die einzige objektorientierte Sprache, da die 3 Grundsätze der objektorientierten Programmierung darauf basieren, dass sie auf Nachrichtenübergang, das du hast Isolation zwischen Objekten und haben Polymorphismus.

Asynchrone Nachrichten, die wie im ereignisgesteuerten Systeme und in Erlang passieren, ist auch eine sehr gute Möglichkeit, Systeme zu entkoppeln und lose Kopplung ist wichtig in komplexen Systemen. Mit einem ausreichend entkoppelten System können Sie das System während des Laufens entwickeln, möglicherweise auf verschiedenen Knoten. Unibet machte eine großartige Präsentation darüber: Domain -Event -gesteuerte Architektur

Ich denke jedoch, dass die meisten Code -Wiederverwendung mit Bibliotheken und Frameworks durchgeführt werden.

Die Humble Unix Pipe hat mehr für die Wiederverwendung von Code als alles andere getan, was gekommen und gegangen ist. Objekte waren zufällig eine intuitive Art, Code zu strukturieren, als sie mitkamen, und später begannen die Leute, alles und alles darauf zu nehmen. Im Allgemeinen dienen Objekte für die Kapselung und nicht für die Wiederverwendung von Code, die Wiederverwendung von Code erfordert etwas mehr und die Klassenerbschaftshierarchie ist ein schlechter Ersatz für das, was ein Code -Wiederverwendung -Mechanismus wirklich sein sollte.

Oop ist kein besonderes; Sie können wiederverwendbares Code mit oder ohne OOP erstellen. Reine Funktionen sind besonders wiederverwendbar: zum Beispiel, java.lang.math.sqrt(double) Nimmt eine Nummer ein und gibt eine Nummer heraus. Kein OOP, aber definitiv wiederverwendbarer als die meisten Code da draußen.

Aus einer funktionalen Programmieransicht geht es bei OOP hauptsächlich um die Verwaltung des Status.

In der funktionalen Programmierung können Sie problemlos Hunderte nützlicher Funktionen für Listen haben: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/data-list.html.

Würden Sie Hunderte von Methoden in einer Listenklasse haben? Öffentliche Methoden werden als Schnittstelle zum internen Zustand angesehen, den Sie klein halten möchten.

Leider duplizieren manche Menschen anstelle von (neu) viele kleine Funktionen die Funktionalität. Für mich liegt das daran, dass OOP fördert die Wiederverwendung von Code nicht so viel wie funktionale Programmierung.

Für mich, ja, aber nicht die ganze Zeit, und es hätte auf andere Weise getan werden können.

Die meiste Zeit durch Erstellen einer abstrakten Basisklasse und durch Erstellen konkreter Implementierungen dieser Klasse.

Auch viele Frameworks nutzen die Vererbung, um eine Wiederverwendung von Code bereitzustellen (Delphi, Java, .NET sind nur einige, die sich sofort eingehen).

Das heißt nicht, dass viele Versorgungsbibliotheken und Code -Ausschnitte den Job nicht hätte erledigen können, aber eine gut gestaltete Objekthierarchie hat etwas Erfreuliches.

Nach meiner Erfahrung habe ich mehr Erfolg mit dem Nutzung von "wiederverwendbaren" Code durch generische Programmiermöglichkeiten (wie C ++ - Vorlagen) als ich OOP -Prinzipien wie Vererbungshierarchien hatte.

OOP ist zu offen für eine wirksame Wiederverwendung.

Es gibt zu viele Möglichkeiten, um wiederzuverwenden. Jede öffentliche Klasse fragt: "Machen Sie eine neue Instanz von mir!", jede öffentliche Methode sagt: "Ruf mich an!", jede geschützte Methode ergibt: "Überschreiben Sie mich!" - und all diese Möglichkeiten der Wiederverwendung sind anders, Sie haben unterschiedliche Parameter, sie erscheint in unterschiedlichem Kontext, alle haben ihre unterschiedlichen Regeln, wie sie es aufrufen/erweitern/überschreiben.

API ist besser, es ist eine strenge Untergruppe von OOP (oder Nicht-Oop-Punkten), aber im wirklichen Leben sind APIs überfüllt und für immer wachsen, es gibt immer noch zu viele Verbindungspunkte. Außerdem kann eine gute API das Leben erleichtern, es ist die beste Möglichkeit, eine Schnittstelle für OOP bereitzustellen.

Datadlow Paradigma Bietet eine strenge Schnittstelle für Komponenten, sie haben Ports der folgenden Typen:

  • Verbraucher (Eingaben) und
  • Hersteller (Ausgänge).

Hängt von der Domäne ab, es gibt einige Pakettypen, sodass Verbraucher und Hersteller verbunden werden können. Sie haben die gleichen (oder kompatiblen) Ports. Der schönste Teil davon, dass es visuell erledigt werden kann, da es keine Parameter oder Orler -Optimierungen an Verbindungen gibt, verbinden sie wirklich nur einen Verbraucher und einen Produzenten.

Ich war ein bisschen unklar, Sie können einen Blick darauf werfen "DataFlow" -Tag auf Stackoverflow, oder Wikipedia "Datenfow -Programmierung" oder Wikipedia "Flow-basierte Programmierung".

(Außerdem habe ich ein DataFlow -System in C ++ geschrieben. OOP und DF sind also keine Feinde, DF ist eine organisatorische Weise auf höherer Ebene.)

In COMMOLLISP gibt es viele Mittel, um Wiederverwendung zu erreichen:

  • Dynamisches Tippen, standardmäßig generisch sein Code generisch

  • Imperative Abstraktionen, dh Unterroutinen

  • Objektorientierung mit mehreren Vererbung und Mehrfachversand

  • Syntaxabstraktion, die Fähigkeit, neue syntaktische Konstrukte zu definieren oder Kesselplattencode abzukürzen

  • Funktionsabstraktionen, Verschlüsse und Funktionen mit hoher Ordnung

Wenn Sie versuchen, die Commonlisp -Erfahrung mit anderen Sprachen zu vergleichen beide objektorientierte und funktionale Abstraktionen. Sie sind komplementärer als alternativ: Ohne einen von ihnen werden Sie gezwungen, die fehlenden Funktionen auf ungeschickte Weise neu zu implementieren. Sehen Sie beispielsweise Funkungsklassen, die als Verschluss und Musteranpassung verwendet werden, um nicht erweiterbarer Methodenversand zu erhalten.

Es gibt wirklich keine "Wiederverwendung" der Art und Weise, wie die Leute es beschreiben. Wiederverwendung ist ein zufällig Eigentum von irgendetwas. Es ist schwierig, dafür zu planen. Was die meisten Menschen meinen, wenn sie über "Wiederverwendung" sprechen, ist "Verwendung". Es ist ein weitaus weniger attraktiver und aufregender Begriff. Wenn Sie eine Bibliothek verwenden, verwenden Sie sie normalerweise für das, wofür sie beabsichtigt war. Sie sind nicht Wiederverwenden, es sei denn, Sie machen etwas wirklich Verrücktes damit.

In diesem Sinne geht es bei der Wiederverwendung in der realen Welt darum, Dinge neu zu purposieren. Ich kann diese Sitze hier wiederverwenden und sie zu bilden ... ein Bett! Kein sehr bequemes Bett, aber das kann ich. Das ist nicht ihre primäre Verwendung. Ich verwende sie außerhalb ihres ursprünglichen Bereichs der Anwendbarkeit wieder. [...] Morgen werde ich nach Großbritannien zurückfliegen. Ich werde nicht Wiederverwenden Sie das Flugzeug wieder. Ich werde es nur für den Zweck verwenden, für den es beabsichtigt war, es gibt nichts Besonderes oder Aufregendes daran.

- Kevlin Henney

Ich werde lächerlich riskieren und gestehen, ich benutze OOP erst in letzter Zeit. Es kommt nicht automatisch zu mir. Die meiste Erfahrung beinhaltet relationale Datenbanken, also denke ich in Tabellen und Verbindungen. Es gibt Behauptungen, dass es von Anfang an besser ist, es zu lernen, was vermeidet, Ihr Denken in Bezug auf das Programmieren neu zu verdrahten. Ich habe diesen Luxus nicht und weigere mich, meine Karriere über eine Elfenbeinturmtheorie zu verschrotten. Wie alles andere werde ich es herausfinden.

Zuerst dachte ich, dass das ganze Konzept keinen Sinn ergab. Es schien nur unnötig und zu viel Mühe. Ich weiß, das ist verrücktes Gespräch. Offensichtlich braucht es ein gewisses Maß an Verständnis, bis Sie die Vorteile von irgendetwas schätzen oder es für bessere Methoden abweisen können.

Die Wiederverwendung von Code erfordert die Bereitschaft, den Code nicht zu wiederholen, ein Verständnis dafür, wie er erledigt werden kann, die Planung im Voraus. Sollten Sie vermeiden, Code wiederzuverwenden, wenn Sie entschieden haben, dass Sie einen Fall haben, in dem es sich einfach nicht lohnt? Und keine Sprache ist so streng oo, dass es einen Fehler macht, wenn sie denkt, Sie hätten Code von einer anderen Klasse geerbt haben sollten. Bestenfalls bieten sie eine Umgebung, die der Implementierung fördert.

Ich denke, der größte Vorteil von OOP ist die allgemeine Akzeptanz, wie Code organisiert werden sollte. Alles andere ist Soße. Ein Team von Programmierern ist sich möglicherweise nicht vollständig darin überein, wie alle Klassen strukturiert werden sollen, aber sie sollten in der Lage sein, den Code zu finden.

Ich habe genug Verfahrenscode gesehen, um zu wissen, dass er überall sein könnte, und manchmal ist er überall.

Oop gibt es dir mehr Möglichkeiten zur Wiederverwendung von Code. Das ist alles.

Horizontale Wiederverwendung: Aspekte, Merkmale, Transplantate

Das klassische OO fällt manchmal auf die Wiederverwendung von Codes zurück, insbesondere wenn Sie alle Vererbung verrückt machen, weil Sie eine bessere Möglichkeit haben, die tatsächliche Funktionalität zwischen den Klassen zu teilen. Für dieses Problem wurden horizontale Wiederverwendungsmechanismen erstellt, wie z. B. AOP, Merkmale und Transplantate.

Aspektorientierte Programmierung

Ich betrachte AOP als die fehlende Halborange von OOP. AOP ist nicht wirklich so bekannt, aber es hat es zu Produktionscode geschafft.

Ich werde es in einfachen Worten versuchen, sich in einfachen Worten zu erklären: Stellen Sie sich vor, Sie können Funktionen mit einer speziellen Struktur injizieren und filtern können, die als Aspekt bezeichnet werden. Diese Aspekte haben "Methoden", die definieren, was und wie durch beeinflusst wird durch Betrachtung, aber zur Kompilierzeit wird dieser Prozess genannt Weberei.

Ein Beispiel wäre ein Aspekt, der "für alle Methoden bestimmter Klassen, die mit GET beginnen, lautet, dass Ihr Programm in eine Protokolldatei die Daten und die Zeit, die es gab, in eine Protokolldatei schreiben.

Sehen Sie sich diese beiden Gespräche an, wenn Sie AOP besser verstehen möchten:

Merkmale und Transplantate

Züge sind ein weiteres Konstrukt für die Definition wiederverwendbarer Code, die OOP ergänzen, sie sind ähnlich wie Mischungen, aber sauberer.

Anstatt sie zu erklären, gibt es ein großer PHP RFC, der beide erklärt. Merkmale kommen übrigens zu PHP, sie sind bereits zum Kofferraum verpflichtet.

Zusammenfassend

OOP ist meiner Meinung nach der Schlüssel für die Modularität, und wie wir es heute allgemein kennen OOP ist noch unvollständig.

OOP bietet eine Reihe nützlicher Tools, mit denen Sie Code schreiben können, die an mehr Stellen verwendet werden können, als Sie ohne diese Tools können. Wenn Sie a schreiben PrintIt Funktion, die alte Objekte und Anrufe nimmt .toString() Darauf haben Sie diesen Code wiederverwendet, sobald Sie ihn mit mehr als einer Art Objekt anrufen. Mit diesen Werkzeugen, Jede Codezeile tut mehr.

Die funktionale Programmierung ist derzeit bei den Hipstern sehr heiß. Es bietet Ihnen eine Ganz getrennt Set von Tools, um jede Codezeile mehr zu ermöglichen. Es ist wahrscheinlich nicht besser oder funktioniert, bietet aber ein weiteres Tool in der Toolbox.

(Es gab eine verrückte Idee für eine zusätzliche Ebene der objektorientierten Wiederverwendung: Die Idee war, dass wir eine einzelne definieren konnten Customer Klasse und verwenden Sie es in jeder Anwendung, die wir geschrieben haben. Dann wären die Anwendungen hier und da nur ein kleiner Kleber. Das hat nicht funktioniert. Das heißt aber nicht, dass das OO fehlgeschlagen ist oder sogar diese Wiederverwendung fehlgeschlagen ist. Die grundlegenden Arten der Code-Wiederverwendung in Anwendungen ermöglichten es, Anwendungen zu schreiben, die mehr bewirkten und schneller schreiben.)

Lesen Sie die oben genannten Beiträge, ein paar Bemerkungen:

  • Viele denken, dass die Wiederverwendung von Code in OOP die Vererbung impliziert. Ich stimme nicht zu. Schnittstellen und Verträge sind der Kern, um die Wiederverwendung in OOP -Systemen zu codieren. OOP ist ein grauer Box -Versuch, eine Komponententechnologie zu erstellen.
  • Der Unterschied zwischen domänenspezifischem und generischen "Frameworks" als Gegenstand von Wiederverwendung ist für mich zu abstrakt. Meiner Ansicht nach kann eine Komponente (ein prägnanter, minimaler und wiederverwendbarer Schnittstellenvertrag und die Implementierung dahinter) nur durchgeführt werden, wenn das Problem, das es behandelt, gut verstanden wird. Eine domänenspezifische Komponente, die es nicht-Domänen-Experten ermöglicht, ihre Arbeit mit weniger Kenntnissen über die Domäne zu erledigen, ist eine (neu) nützliche Komponente. Benutzer müssen die Schnittstelle weniger verstehen, weniger als die Feinheiten der Problemdomäne.
  • Wiederverwendungsstufen oft vergessen: Ideenwiederverwendung, Wiederverwendung, Architektur-/Design-Wiederverwendung, Wiederverwendung von Schnittstellen, Wiederverwendung von Tests. Die Wiederverwendung von Code ist nicht immer günstig. Aber es ist ein großer Sparer häufig, sich an eine bestimmte Architektur zu halten, um ein neues, ähnliches Produkt anzugehen.
  • Die OOP-Designmuster (Gamma et al.) In meinen Augen, die auf taktische Implementierungstechniken ausgearbeitet wurden, anstatt im Kontext der Wiederverwendung von Code in größerem Maßstab von Bedeutung zu sein. Sie helfen dabei, eine Anwendung mit OOP-Elementen zu schreiben, aber ich würde sie nicht als Lösung für die Frage "Code-Wiederverwendung" betrachten, die über eine einzige Anwendung hinausgeht.
  • Vielleicht ist es nicht fair: 20 Jahre C/C ++/C# Erfahrung und 6 Monate funktionelle Programmierung (F#). Ein Hauptelement für die Wiederverwendung ist: Menschen müssen leicht "die Schnittstelle" finden, sie studieren, verstehen und dann verwenden. Reine funktionelle Programmierung macht es mir nicht leicht, Struktur, Kandidaten für die Wiederverwendung oder wo alles beginnt und wo alles endet. Der so gelobte "syntaktische Zucker" ist oft Salz in meinen Augen und hindert mich daran, leicht zu sehen, was passiert. Daher würde ich weniger wahrscheinlich versuchen, ein Funktional wiederzuverwenden (was ist es-eine Reihe von Funktionen?), Die ich möglicherweise nicht einmal sehen kann (faule Bewertung, Monaden, ...). Versteh mich nicht falsch, funktionales Programmieren hat sehr coole Seiten, aber alle Stärken, die ich mit einem guten Maß an Zweifel sehe. Ich bin sehr neugierig, was die postfunktionale Zukunft bringt und hoffe, sie zu sehen, bevor ich in den Ruhestand bin;)
  • Spezifikation, Design, Implementierung sind gekoppelt, aber nicht leicht durch die "Gleiche". Viel wichtiger für die zunehmende zukünftige Produktivität als ein neues Programmierparadigma besteht darin, die Lücke zu schließen (automatisiertes Denken, Rückverfolgbarkeit), die gegenseitigen Vorteile zwischen diesen Ansichten. Formalisierte Spezifikationssprachen, standardisierte Testnotationen (z. B. TTCN3) und Programmiersprachen, die die Überprüfung von Schnittstellen und Verträgen gegen Spezifikationen ohne Kommentarverletzung unterstützen, könnten das dringend am dringendsten sein.

Das Problem ist subtiler imho:

  1. Oop ist a Tolle Methode zum Strukturieren von Code mit mutablen Zustand. Indem Sie den Staat in Objekte verknüpfen, wird der imperativen staatliche Code verständlicher, da Sie beispielsweise als private Bereiche einer Klasse ausgedrückt werden Zumindest kann dieses bestimmte Zustandsstück nur mit Methoden dieser Klasse geändert werden. (Und Sie können diesen Nutzen leicht durchbrechen, indem Sie die Erbschaft missbrauchen, übrigens.) Dies reicht jetzt genug, aber aber Waaay besser als nicht einmal das zu haben.
  2. Code mit veränderbarem Zustand ist von Natur aus schwer wiederverwenden. Viel härter als Code mit unveränderlichen Datenstrukturen.

So OOP an sich ist nicht schlecht, wenn er POV wiederverwendbarer Code erstellt, aber Die Art von Code, die mit OOP geschrieben werden, sind von Natur aus schwer wiederverwenden.

Ebenfalls, Funktionelle Programmierung Mai führt zu Mehr wiederverwendbarer Code. Aber die Abstraktionen zu erhalten, um einen gesunden Funktionscode zu schreiben, während eine Frist eingehalten wird, ist jedoch möglicherweise nicht machbar. Und "halb rechte" Abstraktionen sind leichter zum Ausdruck des Stils. Und es wird nicht dazu neigen, dazu zu führen Einfacher zuverwenden Code - Ein höheres Abtrktionsniveau bedeutet, dass das Verständnis des Codeverständnisses eine höhere Vorabinvestition durch die begrenzte kognitive Kapazität der Programmierer erfordert.

Als praktisches Beispiel: Spielcode beinhaltet viel veränderbarer Zustand, denn dies ist die natürliche Möglichkeit, über das Codieren eines Spiels nachzudenken, es sei denn, es ist ein sehr Puzzle-/Algorithmic, so dass er offensichtlich mit OO strukturiert wird. Und natürlich ist es schwer wiederzuverwenden. Aber der gleiche Code, der das gleiche Wissen enthält, Wäre noch schwieriger ohne OOP wiederverwendet. Und neu zu schreiben, um einen funktionalen Stil zu sein Ändern Sie die Art und Weise, wie Sie über diesen Code denken, das Wissen dahinter. Ja, das resultierende Wissen hinter dem Code wäre vielleicht viel klarer, nachdem das OO zu FP umschreiben würde, vielleicht ... aber Die Kosten könnten riesig sein Und es könnte sein Die Art von Kosten, die auch von Leuten bezahlt werden müssten, die den unglaublich klugen und gut abstrahierten Code wiederverwenden möchten, mit dem Sie enden, Paradoxerweise würden die Menschen den Code nicht wiederverwenden, auch wenn er technisch gesehen wiederverwendbarer ist.

... was zur letzten Subtilität führt: Code -Wiederverwendung geht um die Leute | Code Schnittstelle, nicht nur über den Code. OOP leistet eine anständige Aufgabe, diese Benutzeroberfläche zu bedienen, da sie gut mit der Art und Weise, wie viele Leute über viele Arten von Code denken, die heutzutage geschrieben wurden, nachdenken. FP könnte für die Wiederverwendung von Code besser sein, aber imho nicht für Die Art von Code, die die Leute heutzutage tatsächlich schreiben müssen, leicht wiederzuverwenden. Dies wird sich als die Art von Code ändern, die wir für Änderungen schreiben müssen.

PS und wenn jemand sagen möchte, dass "OO nicht um mutable Zustand geht, können Sie auch OO mit unveränderlichen Zustand haben" ... Ich nenne das "FP mit Klassen als Namespaces". Es ist großartig, wenn es für Sie funktioniert, und vermeidet einige Mängel der Modulsysteme einiger Sprache und kann zu wiederverwendbarerem Code führen. Aber das ist nicht oo;)

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top