it-swarm.dev

Erfüllt OOP das Versprechen der Wiederverwendung von Code? Welche Alternativen gibt es, um die Wiederverwendung von Code zu erreichen?

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

Wird Code als OOP definiert, um Projekte produktiver zu machen?

Oder überschaubarer? Oder einfacher zu pflegen? 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, um dieses Ziel zu erreichen. Die Frage betrifft die von OOP angebotene Methode zur Wiederverwendung von Code. War es eine gute Sache? Gibt es bessere Methoden zur Wiederverwendung von Code als Objektorientierung, Unterklassifizierung, Polymorphismus usw.? Welche Wege sind besser? Warum?

Teilen Sie uns Ihre Erfahrungen mit der Wiederverwendung von OOP oder anderen Paradigmen) mit.

56
Maniero

Die Wiederverwendung von Code ist eine ziemlich gute Idee. Nicht großartig.

Ich habe eine Perspektive aus ungefähr 30 Jahren Software-Engineering, die versucht, "wiederzuverwenden".

Ich begann bereits in den 80er Jahren, "Code-Wiederverwendung" als Forschungsthema zu untersuchen, nachdem ich herausgefunden hatte, dass ich das Design eines Betriebssystems, das ich in den frühen 70er Jahren erstellt hatte, für ein anderes Betriebssystem, das ich in den späten 70er Jahren erstellt hatte, wiederverwendet hatte.

Der gute Teil der Wiederverwendung von Code ist die Fähigkeit, bereits vorhandenen Code, der ehrlich zu Gott ist, manchmal wiederzuverwenden. Aber die Welt ist voll Code; Wie können Sie finden, was Sie wollen? Folgendes nenne ich den Wiederverwendungsfluch :

Ich bin der Weihnachtsmann (ok Open Source) und habe eine Tüte mit 1 Milliarde Softwarekomponenten. Sie können jeden von ihnen haben.

Viel Glück bei der Auswahl.

So lösen Sie das Wiederverwendungsproblem gut:

  • der Wiederverwendete muss irgendwie angeben, was er benötigt (Funktion, Leistung, Zielsprache, Umgebungsannahmen, ...).
  • es muss eine Bibliothek mit "wiederverwendbarem" Code vorhanden sein, die nach diesen potenziellen Kriterien auf verschiedene Weise indiziert wurde
  • es muss ein Mechanismus vorhanden sein, um Kandidatenelemente auszuwählen (bei einer Milliarde Elementen kann man sie nicht alle persönlich betrachten).
  • es muss eine Möglichkeit geben, zu charakterisieren, wie weit die ausgewählten Kandidaten von der Spezifikation entfernt sind
  • es sollte ein regulärer Prozess vorhanden sein, damit der Wiederverwendete 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 ihre Slots überschreiben. OOP bietet keinen andere Hilfe).
  • all dies muss eindeutig billiger sein, als es einfach neu zu codieren

Im Laufe der Jahre wurde meistens festgestellt, dass Code, um wiederverwendbar zu sein, für diesen Zweck entwickelt werden muss oder zu viele implizite Annahmen enthält. Die erfolgreichsten Bibliotheken zur Wiederverwendung von Code waren eigentlich ziemlich klein. Bibliotheken und Frameworks sind wohl "wiederverwendbarer" Code und äußerst erfolgreich. Java und C # sind nicht erfolgreich, weil sie ziemlich gute Computersprachen sind, sondern weil sie über große, gut gestaltete, implementierte und dokumentierte Bibliotheken verfügen. Die Leute sehen sich jedoch nicht den Quellcode in der an Bibliotheken rufen einfach eine gut dokumentierte API auf (die allgemein verwendbar sein soll).

Was die Wiederverwendung von Code nicht getan hat (OOP auch nicht), ist eine Verbesserung unserer Fähigkeit, Systeme zu codieren, um Größenordnungen.

Ich denke, der Hauptfehler ist, dass jede Art von Code-Wiederverwendung grundsätzlich eingeschränkt ist, da in Code zu viele Annahmen eingebaut sind . Wenn Sie den Code winzig machen, minimieren Sie die Annahmen, aber die Kosten für die Erstellung von Grund auf sind nicht sehr hoch und die Wiederverwendungsgewinne sind nicht effektiv. Wenn Sie die Codeblöcke riesig machen, sind sie in einem neuen Kontext so gut wie nutzlos. Wie Gulliver sind sie durch eine Million winziger Fäden 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, um Code zu konstruieren . Wenn wir dies tun können, können wir dieses Wissen anwenden, um den Code zu erstellen, den wir benötigen, und dabei die aktuellen Annahmen behandeln.

Dazu benötigt man zur Charakterisierung von Softwarekomponenten immer noch die gleiche Spezifikationsfähigkeit (man muss noch sagen, was man will!). Aber dann wenden Sie dieses "Konstruktions" -Wissen auf die Spezifikationen an, um generieren den gewünschten Code.

Als Community sind wir noch nicht sehr gut darin. 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 möglich ist.

Eine wichtige Maschine, die dafür benötigt wird, sind mechanische Werkzeuge zum Akzeptieren von "Komponentenbeschreibungen" (dies sind nur formale Dokumente und können wie Programmiersprachen analysiert werden) und zum Anwenden von Programmtransformationen = zu ihnen.

Compiler tun dies bereits: -} Und sie sind wirklich gut in der Klasse von Problemen, die sie angehen.

UML-Modelle mit Codegenerierung sind ein Versuch, dies zu tun. Kein sehr guter Versuch; In den meisten UML-Modellen heißt es so ziemlich "Ich habe Daten, die so aussehen". Es ist ziemlich schwierig, ein echtes Programm zu generieren, wenn die Funktionalität weggelassen wird.

Ich versuche praktische Programmtransformationssysteme, ein Tool namens DMS zu erstellen. Wurde ziemlich abgelenkt, indem Programmtransformationen nicht so sehr auf abstrakte Spezifikationen angewendet wurden, um Code zu generieren, sondern auf alten Code, um ihn zu bereinigen. (Dies sind die gleichen Probleme in der Zusammenfassung!). (Das Bauen solcher Werkzeuge nimmt viel Zeit in Anspruch; ich mache das seit 15 Jahren und in der Zwischenzeit muss man essen).

DMS verfügt jedoch über die beiden wichtigsten Eigenschaften, die ich oben beschrieben habe: die Fähigkeit, beliebige formale Spezifikationen zu verarbeiten und "Codegenerierungswissen" als Transformationen zu erfassen und bei Bedarf anzuwenden. Und bemerkenswerterweise generieren wir in einigen Sonderfällen einen ziemlich interessanten Code aus Spezifikationen. DMS wird größtenteils selbst erstellt, um seine Implementierung zu generieren. Das hat für uns zumindest einen Teil des Versprechens der (Wissens-) Wiederverwendung erreicht: äußerst signifikante Produktivitätsgewinne. Ich habe ein Team von ungefähr 7 technischen Leuten; Wir haben wahrscheinlich 1-2 MSLOC "Spezifikationen" für DMS geschrieben, haben aber einige 10MSLOC generierten Codes.

Zusammenfassung: Wiederverwendung von Generationswissen ist der Gewinn, nicht Wiederverwendung von Code.

35
Ira Baxter

Die Wiederverwendung von Code wird in OOP, aber auch in der funktionalen Programmierung erreicht. Jedes Mal, wenn Sie einen Codeblock nehmen und ihn für den Rest Ihres Codes aufrufbar machen, sodass Sie diese Funktionalität verwenden können an anderer Stelle wird Code wiederverwendet.

Diese Art der Wiederverwendung von Code macht den Code auch einfacher zu verwalten, da durch Ändern dieses einen aufrufbaren Blocks alle Stellen geändert werden, an denen er aufgerufen wird. Ich würde sagen, dass dieses Ergebnis auch die Qualität und Lesbarkeit erhöht.

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

Aus Wikpedia :

Objektorientierte Programmierung hat Wurzeln, die bis in die 1960er Jahre zurückreichen. Da Hardware und Software immer komplexer wurden, wurde die Verwaltbarkeit häufig zu einem Problem. Die Forscher untersuchten Möglichkeiten zur Aufrechterhaltung der Softwarequalität und entwickelten eine objektorientierte Programmierung, um teilweise häufige Probleme anzugehen, indem sie diskrete, wiederverwendbare Einheiten der Programmierlogik stark betonten [Zitieren erforderlich]. Die Technologie konzentriert sich eher auf Daten als auf Prozesse. Die Programme bestehen aus autarken Modulen ("Klassen"), von denen jede Instanz ("Objekte") alle Informationen enthält, die zur Manipulation ihrer eigenen Datenstruktur ("Mitglieder") erforderlich sind. Dies steht im Gegensatz zu der seit vielen Jahren vorherrschenden modularen Programmierung, die sich eher auf die Funktion eines Moduls als speziell auf die Daten konzentrierte, aber gleichermaßen für die Wiederverwendung von Code und autarke wiederverwendbare Einheiten der Programmierlogik vorgesehen war, um die Zusammenarbeit zu ermöglichen durch die Verwendung von verknüpften Modulen (Unterprogrammen). Bei diesem konventionelleren Ansatz, der immer noch besteht, werden Daten und Verhalten tendenziell getrennt betrachtet.

36
Chris

Ja und Nein

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

  1. Wiederverwendung von Code innerhalb eines einzelnen Projekts. OO ist perfekt dafür geeignet. Eine gut gestaltete Anwendung hat die Beziehungen der modellierten Welt genau abgebildet und so doppelten Code so weit wie möglich eliminiert möglich und ratsam. 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 von Drittanbietern Dies scheint mit oder ohne OO gleich gut zu funktionieren.
  3. Wiederverwendung von Code für verschiedene Zwecke Das größte Versprechen von OO zur Wiederverwendung von Code war, dass Code, der einmal für eine Anwendung geschrieben wurde, später für eine andere wiederverwendet werden kann, die nicht speziell entwickelt wurde zum. Dies war der letzte Schrei, als der Begriff OO durch die Türen höherer Verwaltungsbüros drang und OO ihn überhaupt nicht erreichte. Es stellte sich heraus, dass der Zweck ein entscheidender Aspekt des OO -Designs war (und möglicherweise der gesamte Verfahrenscode, aber das ist nur meine Theorie), und Versuche, Code neu zu verwenden, endeten in Wartungskatastrophen. (Die bekannten Antimuster eines alten Frameworks, das niemand zu modifizieren wagt, und sein Freund, die leicht unterschiedlichen Frameworks für jede App, stammen normalerweise von hier.)
15
biziclop

Ich stimme Chris zu, funktionale Programmierung ist ein guter Weg, um Code wiederzuverwenden.

Viele Programme haben wiederkehrende Codestrukturen. Hierzu werden in der OOP-Welt einige Entwurfsmuster verwendet, dies kann jedoch durch rekursive Funktionen und erreicht werden. Pattern Matching in funktionalen Programmiersprachen. Weitere Informationen hierzu finden Sie im ersten Kapitel in Real World Functional Programming .

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

Das Problem mit objektorientierten Sprachen ist, dass sie all diese implizite Umgebung haben, die sie mit sich herumtragen. Sie wollten eine Banane, aber Sie bekamen einen Gorilla, der die Banane und den gesamten Dschungel hielt.

Funktionen höherer Ordnung sind auch sehr nützlich, wenn es um die Wiederverwendung von Code geht, z. map und foldr das ist die Grundlage für Googles MapReduce .

Die asynchrone Nachrichtenübermittlung ist auch eine gute Möglichkeit, komplexe Software zu organisieren, und einige Informatiker geben an, dass angenommen wurde, dass Objekte asynchron miteinander kommunizieren, wie in - Tell, frag nicht OOP Prinzip. Mehr dazu in Objektorientierte Programmierung: Der falsche Pfad? waren Joe Armstrong wird zitiert:

Ich begann mich zu fragen, was objektorientierte Programmierung ist und dachte, Erlang sei nicht objektorientiert, sondern eine funktionale Programmiersprache. Dann sagte mein Betreuer der Dissertation: "Aber du liegst 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 könnte die einzige objektorientierte Sprache sein, da die 3 Grundsätze der objektorientierten Programmierung darin bestehen, dass sie auf Nachrichtenübermittlung basiert , dass Sie Isolation zwischen Objekten haben und Polymorphismus haben.

Die asynchrone Nachrichtenübermittlung wie in ereignisgesteuerten Systemen und in Erlang ist auch eine sehr gute Möglichkeit, Systeme zu entkoppeln, und lose Kopplung ist in komplexen Systemen wichtig. Mit einem ausreichend entkoppelten System können Sie das System während der Ausführung weiterentwickeln, möglicherweise auf verschiedenen Knoten. Unibet hat diesbezüglich eine großartige Präsentation gemacht: Domain Event Driven Architecture

Ich denke jedoch, dass der größte Teil der Wiederverwendung von Code mithilfe von Bibliotheken und Frameworks erfolgt.

13
Jonas

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-reuse/

Hier ist der Anfang des Beitrags:

Diese Branche ist mit der Wiederverwendung beschäftigt.

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

Einige gehen sogar so weit zu sagen, dass der ganze Punkt der Objektorientierung die Wiederverwendung war - es war nicht so, die Kapselung war die große Sache. Nach dieser Komponentenorientierung sollte die Wiederverwendung stattfinden. Anscheinend hat das auch nicht so gut geklappt, denn hier setzen wir jetzt unsere wiederverwendbaren Hoffnungen auf Serviceorientierung.

Es wurden ganze Musterbücher darüber geschrieben, wie mit der Ausrichtung des Tages eine Wiederverwendung erreicht werden kann. Services wurden in jeder Hinsicht klassifiziert, um dies zu erreichen, von Entity-Services und Aktivitätsservices über Prozessservices und Orchestrierungsservices. Das Erstellen von Diensten wurde als Schlüssel zur Wiederverwendung und Erstellung wiederverwendbarer Dienste angepriesen.

Ich könnte Sie genauso gut in das schmutzige kleine Geheimnis einweihen:

Wiederverwendung ist ein Irrtum

13
Tony

Die bescheidene Unix-Pipe hat mehr für die Wiederverwendung von Code getan als alles andere, was gekommen und gegangen ist. Objekte waren zufällig eine intuitive Art, Code zu strukturieren, als sie kamen, und später begannen die Leute, alles und jeden darauf zu heften. Im Allgemeinen dienen Objekte der Kapselung und nicht der Wiederverwendung von Code. Die Wiederverwendung von Code erfordert etwas mehr und die Hierarchie der Klassenvererbung ist ein schlechter Ersatz für das, was ein Mechanismus zur Wiederverwendung von Code eigentlich sein sollte.

6
davidk01

OOP ist nichts Besonderes; Sie können wiederverwendbaren Code mit oder ohne OOP erstellen. Reine Funktionen sind besonders wiederverwendbar: Zum Beispiel nimmt Java.lang.math.sqrt(double) eine Zahl ein und gibt eine Zahl aus. Kein OOP, aber definitiv wiederverwendbarer als der meiste Code da draußen.

4
Joonas Pulakka

Aus Sicht der funktionalen Programmierung OOP geht es hauptsächlich um die Verwaltung des Status.

In der funktionalen Programmierung können Sie leicht 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 .

Hätten Sie Hunderte von Methoden in einer List-Klasse? Öffentliche Methoden werden als Schnittstelle zum internen Status betrachtet, den Sie klein halten möchten.

Leider duplizieren manche Leute die Funktionalität, anstatt viele kleine Funktionen (erneut) zu verwenden. Für mich liegt das daran, dass OOP ) die Wiederverwendung von Code nicht so sehr fördert wie die funktionale Programmierung.

4

Für mich ja, aber nicht die ganze Zeit, und es hätte auch anders gemacht werden können.

Meistens durch Erstellen einer abstrakten Basisklasse und Erstellen konkreter Implementierungen dieser Klasse.

Auch viele Frameworks nutzen die Vererbung, um die Wiederverwendung von Code zu ermöglichen (Delphi, Java, .Net sind nur einige, die sofort in den Sinn kommen).

Das heißt nicht, dass viele Dienstprogrammbibliotheken und Codeausschnitte den Job nicht auch erledigt haben könnten, aber eine gut gestaltete Objekthierarchie hat etwas Angenehmes.

3
Chris Buckett

Nach meiner Erfahrung hatte ich mehr Erfolg bei der Nutzung von "wiederverwendbarem" Code durch generische Programmierfunktionen (wie C++ - Vorlagen) als bei der Verwendung von OOP Prinzipien wie Vererbungshierarchien).

3
Charles Salvia

OOP ist zu offen für eine effektive Wiederverwendung.

Es gibt zu viele Möglichkeiten zur Wiederverwendung. Jede öffentliche Klasse fragt: "mache eine neue Instanz von mir!", jede öffentliche Methode sagt: "call me!", jede geschützte Methode ergibt: = "überschreibe mich!" - und alle diese Arten der Wiederverwendung sind unterschiedlich , sie haben unterschiedliche Parameter, sie erscheinen in unterschiedlichen Kontext haben alle ihre unterschiedlichen Regeln, wie man es aufruft/erweitert/überschreibt.

[~ # ~] api [~ # ~] ist besser, es ist eine strikte Teilmenge von OOP (oder nicht) -oop) Punkte, aber im wirklichen Leben sind APIs überfunktioniert und wachsen ständig. Es gibt immer noch zu viele Verbindungspunkte. Außerdem kann eine gute API das Leben erleichtern. Dies ist der beste Weg, um eine Schnittstelle für OOP bereitzustellen.


Das Datadlow-Paradigma bietet eine strikte Schnittstelle für Komponenten. Sie haben Ports der folgenden Typen:

  • verbraucher (Inputs) und
  • produzenten (Outputs).

Abhängig von der Domäne gibt es einige Pakettypen, sodass Verbraucher und Hersteller verbunden werden können, wenn sie dieselben (oder kompatible) Ports haben. Das Schönste daran ist, dass es visuell gemacht werden kann, weil es keine Parameter oder andere Änderungen an Verbindungen gibt, sie verbinden wirklich nur einen Verbraucher und einen Produzenten.

Ich war ein bisschen unklar, Sie können einen Blick auf "Datenfluss" -Tag auf StackOverflow oder Wikipedia "Datenflussprogrammierung" oder Wikipedia "Flussbasierte Programmierung" werfen " .

(Außerdem habe ich ein Datenflusssystem in C++ geschrieben. Also OOP und DF sind keine Feinde, DF) ist ein übergeordneter Organisationsweg.)

2
ern0

In CommonLisp gibt es viele Möglichkeiten, um eine Wiederverwendung zu erreichen:

  • dynamische Eingabe, wobei Ihr Code standardmäßig generisch ist

  • imperative Abstraktionen, d. h. Unterprogramme

  • objektorientierung mit Mehrfachvererbung nd Mehrfachversand

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

  • funktionale Abstraktionen, Abschlüsse und Funktionen höherer Ordnung

Wenn Sie versuchen, die CommonLisp-Erfahrung mit anderen Sprachen zu vergleichen, werden Sie feststellen, dass das Hauptmerkmal, das die Wiederverwendung von Code erleichtert, das Vorhandensein von sowohl objektorientierten als auch funktionalen Abstraktionen ist. Sie ergänzen sich mehr als Alternativen: Ohne eine davon müssen Sie die fehlenden Funktionen ungeschickt neu implementieren. Siehe zum Beispiel Funktionsklassen, die als Abschlüsse und Mustervergleich verwendet werden, um einen nicht erweiterbaren Methodenversand zu erhalten.

2
Andrea

OOP bietet Ihnen mehr Möglichkeiten, Code wiederzuverwenden. Das ist alles.

1
Steven A. Lowe

Es gibt wirklich keine "Wiederverwendung", wie die Leute es beschreiben. Wiederverwendung ist eine zufällige Eigenschaft von irgendetwas. Es ist schwer zu planen. Was die meisten Leute meinen, wenn sie über "Wiederverwendung" sprechen, ist "Verwendung". Es ist ein weit weniger attraktiver und aufregender Begriff. Wenn Sie eine Bibliothek verwenden, verwenden Sie sie normalerweise für das, wofür sie bestimmt war. Sie verwenden es nicht, 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 definieren. Ich kann diese Sitze hier wiederverwenden und sie neu anordnen, um ... ein Bett zu bilden! Kein sehr bequemes Bett, aber das kann ich. Das ist nicht ihre primäre Verwendung. Ich verwende sie außerhalb ihres ursprünglichen Anwendungsbereichs wieder. [...] Morgen werde ich nach Großbritannien zurückfliegen. Ich werde nicht das Flugzeug wiederverwenden. Ich werde es nur für den Zweck verwenden, für den es bestimmt war, daran ist nichts Besonderes oder Aufregendes.

- Kevlin Henney

1
fredoverflow

Horizontale Wiederverwendung: Aspekte, Merkmale, Transplantate

Classic OO hat manchmal einen Mangel an Code-Wiederverwendung, insbesondere wenn Sie alle Vererbungen verrückt machen, weil es keine bessere Möglichkeit gibt, die tatsächliche Funktionalität zwischen Klassen zu teilen. Für dieses Problem wurden horizontale Wiederverwendungsmechanismen erstellt, z als 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 zum Produktionscode geschafft.

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

Ein Beispiel wäre ein Aspekt, der besagt, dass "für alle Methoden bestimmter Klassen, die mit get beginnen, Ihr Programm die erhaltenen Daten und die Zeit, zu der sie abgerufen wurden, in eine Protokolldatei schreibt".

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

Eigenschaften & Transplantate

Traits sind ein weiteres Konstrukt zum Definieren von wiederverwendbarem Code, der OOP ergänzt. Sie ähneln mixins , sind jedoch sauberer.

Anstatt sie zu erklären, gibt es einen großartigen PHP RFC, der beide erklärt . Eigenschaften kommen zu PHP Übrigens, sie sind bereits an Trunk gebunden.

Zusammenfassend

OOP ist meiner Meinung nach immer noch der Schlüssel zur Modularität und wie wir es heute allgemein kennen . OOP ist immer noch unvollständig .

1
dukeofgaming

Ich werde Spott riskieren und gestehen, ich habe erst vor kurzem OOP] verwendet. Es kommt nicht automatisch zu mir. Der größte Teil meiner Erfahrung bezieht sich auf relationale Datenbanken, also denke ich nach Es gibt Behauptungen, dass es besser ist, es von Anfang an zu lernen, um zu vermeiden, dass Sie Ihr Denken beim Programmieren neu verdrahten müssen. Ich habe diesen Luxus nicht und weigere mich, meine Karriere über eine Elfenbeinturm-Theorie zu streichen alles andere werde ich herausfinden.

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

Die Wiederverwendung von Code setzt die Bereitschaft voraus, Code nicht zu wiederholen, ein Verständnis dafür, wie dies erreicht werden kann, und die Vorausplanung. Sollten Sie die Wiederverwendung von Code vermeiden, wenn Sie sich für einen Fall entschieden haben, in dem es sich einfach nicht lohnt? Und keine Sprache ist so streng OO, dass sie einen Fehler auslöst, wenn sie denkt, dass Sie Code von einer anderen Klasse geerbt haben sollten. Bestenfalls bieten sie eine Umgebung, die der Implementierung förderlich ist.

Ich denke, der größte Vorteil von OOP ist die allgemeine Akzeptanz, wie Code organisiert werden sollte. Alles andere ist Sauce. Ein Team von Programmierern ist sich möglicherweise nicht ganz einig darüber, wie alle Klassen strukturiert sein sollen, aber Sie sollten in der Lage sein, den Code zu finden.

Ich habe genug prozeduralen Code gesehen, um zu wissen, dass er überall sein kann, und manchmal ist er überall.

1
JeffO

Lesen Sie die obigen Beiträge, einige Anmerkungen:

  • Viele denken, dass die Wiederverwendung von Code in OOP Vererbung impliziert. Ich stimme nicht zu. Schnittstellen und Verträge sind der Kern für die Wiederverwendung von Code in OOP Systemen. OOP ist ein Gray-Box-Versuch beim Erstellen einer Komponententechnologie.
  • Der Unterschied zwischen domänenspezifischen und generischen "Frameworks" als Gegenstand der Wiederverwendung hält mich für zu abstrakt. Aus meiner Sicht kann eine Komponente (ein prägnanter, minimaler und wiederverwendbarer Schnittstellenvertrag und die dahinter stehende Implementierung) nur durchgeführt werden, wenn das Problem, mit dem sie sich befasst, gut verstanden ist. Eine domänenspezifische Komponente, mit der Nicht-Domain-Experten ihre Arbeit mit weniger Wissen über die Domain erledigen können, ist eine (wieder) nützliche Komponente. Benutzer müssen die Benutzeroberfläche verstehen, weniger die Feinheiten der Problemdomäne.
  • Wiederverwendungsstufen häufig vergessen: Wiederverwendung von Ideen, Wiederverwendung von Spezifikationen, Wiederverwendung von Architektur/Design, Wiederverwendung von Schnittstellen, Wiederverwendung von Testfällen. Die Wiederverwendung von Code ist nicht immer günstig. Es ist jedoch eine große Zeitersparnis, sich häufig an eine bestimmte Architektur zu halten, um ein neues, ähnliches Produkt in Angriff zu nehmen.
  • Die OOP Entwurfsmuster (Gamma et al.) In meinen Augen haben taktische Implementierungstechniken erarbeitet, anstatt im Zusammenhang mit der Wiederverwendung von Code in größerem Maßstab von Bedeutung zu sein. Sie helfen beim Schreiben einer Anwendung mit OOP Elementen, aber ich würde sie nicht als Lösung für die Frage der "Wiederverwendung von Code" über eine einzelne Anwendung hinaus sehen.
  • Vielleicht ist es nicht fair: 20 Jahre C/C++/C # -Erfahrung und 6 Monate funktionale Programmierung (F #). Ein wichtiges Element, um die Wiederverwendung zu ermöglichen, ist: Die Benutzer müssen "die Schnittstelle" leicht finden, studieren, verstehen und dann verwenden. Reine funktionale Programmierung macht es mir nicht leicht, Strukturen, Kandidaten für die Wiederverwendung oder wo alles beginnt und wo alles endet zu sehen. Der so gelobte "syntaktische Zucker" ist oft Salz in meinen Augen, was mich daran hindert, leicht zu sehen, was passiert. Daher würde ich weniger wahrscheinlich versuchen, eine Funktion wiederzuverwenden (was ist das - eine Reihe von Funktionen?), Die möglicherweise versteckte Nebenwirkungen hat, die ich nicht einmal sehen kann (träge Bewertung, Monaden, ...). Versteh mich nicht falsch, funktionale Programmierung hat sehr coole Seiten, aber alle proklamierten Stärken sehe ich mit einem guten Maß an Zweifel. Ich bin sehr gespannt, was die postfunktionale Zukunft bringt und hoffe, sie vor meiner Pensionierung zu sehen;)
  • Spezifikation, Design, Implementierung sind gekoppelt, aber nicht leicht zu durchquerende Ansichten über "das Gleiche". Viel wichtiger für eine höhere zukünftige Produktivität als ein neues Programmierparadigma ist es, die Lücke zu schließen und den gegenseitigen Nutzen zwischen diesen Ansichten zu erhöhen (automatisiertes Denken, Rückverfolgbarkeit). Formalisierte Spezifikationssprachen, standardisierte Testnotationen (z. B. ttcn3) und Programmiersprachen, die die Überprüfung von Schnittstellen und Verträgen anhand von Spezifikationen ohne Kommentarabfälle unterstützen, sind möglicherweise das, was wir am dringendsten benötigen.
0
BitTickler

Das Problem ist imho subtiler:

  1. OOP ist eine großartige Methode zum Strukturieren von Code mit veränderlichem Status. Durch das Einkapseln des Zustands in Objekte wird der zwingende zustandsbehaftete Code verständlicher, da Sie beispielsweise wissen, dass mindestens dieses bestimmte Stück ist, wenn ein Zustand als private Felder einer Klasse ausgedrückt wird Der Status kann nur mit Methoden dieser Klasse geändert werden. (Und Sie können diesen Vorteil leicht durch Missbrauch der Vererbung aufheben.) Dies ist jetzt genug, aber waaay besser als nicht einmal dies zu haben.
  2. Code mit veränderlichem Status ist von Natur aus schwer wiederzuverwenden. Viel schwieriger als Code mit unveränderlichen Datenstrukturen.

Also OOP an sich ist nicht schlecht, wenn es darum geht, wiederverwendbaren Code zu erstellen, aber die Arten von Code, die mit OOP geschrieben werden, sind von Natur aus schwer wiederzuverwenden.

Außerdem kann funktionale Programmierung zu wiederverwendbarerem Code führen . Es ist jedoch möglicherweise nicht möglich, die Abstraktionen richtig zu machen, um einen vernünftigen Funktionscode zu schreiben, während eine Frist eingehalten wird. Und "halb rechts" Abstraktionen lassen sich leichter ausdrücken OOP style. Und es führt nicht dazu, dass Code einfacher wiederverwendet werden kann - Ein höheres Maß an Abstraktionen bedeutet, dass das Verständnis des Codes eine höhere Vorabinvestition aufgrund der begrenzten kognitiven Kapazität der Programmierer erfordert.

Als praktisches Beispiel : Spielcode beinhaltet viele veränderbare Zustände, da dies die natürliche Art ist, über das Codieren eines Spiels nachzudenken, es sei denn, es ist ein sehr rätselhaftes/algorithmisches Spiel, sodass es offensichtlich mit strukturiert wird OO. Und natürlich ist es schwer wiederzuverwenden. Aber der gleiche Code, der das gleiche Wissen enthält, wäre ohne OOP noch schwieriger wiederzuverwenden. Und wenn Sie es so umschreiben, dass es ein funktionaler Stil ist, muss möglicherweise die Art und Weise, wie Sie über diesen Code denken, und das Wissen dahinter völlig geändert werden. Ja, das Ergebnis Wissen hinter dem Code wäre viel klarer nach dem OO bis FP vielleicht umschreiben ...) aber die Kosten könnten riesig sein und es könnte die Art von Kosten sein, die auch von Menschen bezahlt werden müssten Wenn Sie den unglaublich intelligenten und gut abstrahierten Code, mit dem Sie am Ende enden, wiederverwenden möchten, würden die Leute den Code paradoxerweise nicht wiederverwenden, selbst wenn er technisch wiederverwendbarer ist.

... was zur letzten Subtilität führt: Bei der Wiederverwendung von Code geht es um die Schnittstelle People | Code, nicht nur um den Code. OOP leistet gute Arbeit bei der Bereitstellung dieser Schnittstelle, da sie gut mit der Anzahl der Leute übereinstimmt, die heutzutage über viele Arten von Code denken. FP ist möglicherweise besser für Code Wiederverwendung, aber imho nicht für einfache Wiederverwendung der Art von Code, die die Leute heutzutage tatsächlich schreiben müssen. Dies wird sich als die Art von Code ändern, die wir brauchen Änderungen schreiben.

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

0
NeuronQ

OOP Bietet eine Reihe nützlicher Tools, mit denen Sie Code schreiben können, der an mehr Stellen verwendet werden kann, als Sie ohne diese Tools hätten. Wenn Sie eine PrintIt -Funktion schreiben, die ein altes Objekt verwendet und .toString() darauf aufruft, haben Sie diesen Code wiederverwendet, sobald Sie ihn mit mehr als einem Objekttyp aufrufen. Mit diesen Tools jede Codezeile leistet mehr.

Die funktionale Programmierung ist momentan unter den Hipstern sehr heiß. Es bietet Ihnen einen ganzen separaten Satz von Werkzeugen, mit denen jede Codezeile mehr kann. Es ist wahrscheinlich nicht besser oder funktioniert, bietet aber ein anderes 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 Customer -Klasse definieren und in jeder Anwendung verwenden können, die wir geschrieben haben. Dann wären Anwendungen nur ein wenig Kleben Sie hier und da. Dies hat nicht funktioniert. Dies bedeutet jedoch nicht, dass die OO fehlgeschlagen oder sogar die Wiederverwendung fehlgeschlagen ist. Die grundlegenden Arten der Wiederverwendung von Code in Anwendungen haben dies ermöglicht Anwendungen zu schreiben, die mehr leisten, und sie schneller zu schreiben.)

0
Sean McMillan