Ich habe oft gehört, dass Objekte im Hinblick auf die Wiederverwendung von Code nicht geliefert wurden. Sind Sie einverstanden? Wenn Sie glauben, dass sie nicht haben, warum nicht?

Nein, nicht unbedingt.

Objekte liefern eine bessere Semantik, Organisation von Code / Funktionalität und möglicherweise eine einfachere Verwendung.

Gut gestaltete Bibliotheken erfüllen das Versprechen der Wiederverwendung von Code, nicht von Objekten an sich.

Ehrlich gesagt bin ich mir nicht sicher, ob "Code-Wiederverwendung" wirklich das ist, wonach jemand strebt (oder zumindest danach sein sollte). Meine Philosophie ist "Softwarekomponenten", dh bessere Wartbarkeit durch gute Schnittstellen und Vermeidung unnötiger Kopplungen. "Wiederverwendung von Code" ist eines der Dinge, die manchmal herausfallen - unnötig duplizierter Code ist ein Zeichen dafür, dass Sie die Dinge falsch organisiert haben, und es ist natürlich mühsam, sie beizubehalten.

Um die Frage ein wenig direkter zu beantworten, gibt es eine Reihe ziemlich guter Werkzeuge, um Wiederholungen zu vermeiden: Vererbung, Merkmale, Delegierung, Funktionen höherer Ordnung usw. Von diesen neigen die Leute dazu, Vererbung mit OO als Ganzem zu verwechseln - und Sie neigen auch dazu, es ein bisschen zu überbeanspruchen, wenn Sie mich fragen. Vielleicht ist das, woher einige der "OO Sucks" -Vibes kommen: Vererbung stecken zu finden, wo es kein natürliches Recht hat zu sein :)

Nein, "Objekte" haben die Wiederverwendung von Code nicht einfacher oder üblicher gemacht. Dieselben Bedenken, die die Wiederverwendung von Code in einem modularen Programm verhindern (das Entwerfen, Testen und Dokumentieren einer Allzweck-API erfordert im Vorfeld erheblich mehr Aufwand als das Schreiben einer einmaligen Routine master of none - Logik, die für die Wiederverwendung vorgesehen ist, ist möglicherweise nicht optimal für die Verwendungszwecke, für die sie tatsächlich verwendet wird Code.

OO ist eine handliche Abstraktion für eine ganze Reihe von Problemen, aber hüten Sie sich vor dem Hype der 80er und 90er Jahre: Es löst die grundlegenden Probleme unseres Handels nicht auf magische Weise mehr, als dass es Ihnen Waffeln macht, während Sie schlafen.

Ich erwarte nicht, dass ALLE Objekte wiederverwendet werden, aber wir haben viele Objekte, die wir für viele verschiedene Projekte wiederverwenden. Wir haben auch Objekte, die nur für ein Projekt wiederverwendet werden. Wir verwenden häufig dieselben Geschäftsobjekte (oder Datenübertragungsobjekte) sowie Geschäftslogikobjekte aus einer Click-Once-Desktop-App, einer Web-App und einer Telefon-App für dasselbe Projekt.

Wo haben Sie gehört, dass OO bei Wiederverwendung nicht liefert? Und was war die Begründung? Vielleicht hat sie das Design ihrer Objekte in diese Situation gezwungen ...

Einige Programmierer kopieren und fügen sie in jeder Sprache und in jedem Stil ein.

Wirklich gute Programmierer können das Kopieren und Einfügen in fast jeder Sprache vermeiden.

Ich finde, dass OO-Muster dazu neigen, die Wiederverwendung zu fördern. Ich habe Java-Code gesehen, der in einem Nicht-OO-Stil geschrieben wurde (bei dem die Daten aufgrund von beschissenem ORM vom Code getrennt wurden), und die Wiederverwendung war wirklich miserabel - aber in OO haben dieselben Programmierer beim Design bessere Arbeit geleistet ( und wiederverwenden).

Auch in Fällen, in denen wir Nicht-OO-Muster oder OO-Anti-Muster wie Setter / Getters, Switch-Anweisungen, anonyme innere Klassen, riesige Funktionen und dergleichen verwenden, ist die Wiederverwendung von Code gesunken, und der Boilerplate-Wert ist erheblich gestiegen.

ps. Ich weiß, dass die Leute Probleme mit dem vorherigen Absatz haben werden, deshalb erkläre ich es ein bisschen.

Setter und Getter verursachen OO-Probleme, weil sie es Ihnen ermöglichen, auf die Mitglieder eines Objekts zuzugreifen (ein Objekt sollte seine EIGENEN Mitglieder manipulieren). Dadurch wird der Code, der auf Ihre Klasse angewendet wird, auf andere Klassen verteilt, sodass Sie die Funktionalität um den Setter / Getter herum kopieren müssen . Dies gilt auch für Eigenschaften - nur weil Eigenschaften einfacher sind, sind sie nicht in allen Situationen "gut".

Der Code in anonymen inneren Klassen kann überhaupt nicht wiederverwendet werden und die Leute vergessen, dass viele Dinge (wie Zuhörer) vollwertige Klassen sein können und sollten - dies gilt auch für Abschlüsse! Wenn Sie eine anonyme innere Klasse verwendet haben, um so etwas wie einen Listener zu implementieren, ist es viel wahrscheinlicher, dass Sie Ihre Implementierung einfach kopieren und einfügen, als den Code in eine Methode oder eine eigene Klasse zu extrahieren und stattdessen aufzurufen. Verschlüsse können auch die Wiederverwendbarkeit verbessern - hängt nur davon ab, wie Sie sie verwenden.

In vielen Fällen bestimmen die verfügbaren Funktionen die Struktur Ihres Codes. OO ist noch leistungsfähiger, wenn es darum geht, Ihnen zu helfen, Ihren gesamten Code zu visualisieren und wie er interagiert, aber das ist eine andere Frage.

Objekte können nicht mehr Code wiederverwenden, als ein Treppensteiger oder ein anderes Fitnessgerät zur Gewichtsreduktion beitragen kann. Entwickler müssen motiviert sein, Werkzeuge richtig einzusetzen.

Sobald Softwareteams der Wiederverwendung von getestetem Code einen höheren Stellenwert beimessen als der Beibehaltung aller Details im Kopf, sehen Sie weitaus feinkörnigere Objekte und Methoden und damit eine stärkere Wiederverwendung von Code.

Ja

OOP bietet Ihnen mehr Möglichkeiten, Code wiederzuverwenden

Nein

es gibt keine silberne Kugel

Es hängt davon ab, ob

auf das, was Sie hineingesteckt haben und was Sie als Gegenleistung erwartet haben!

Ja. Gute objektorientierte Programmierung fördert die Trennung von Bedenken, geringe Kopplung, hohe Kohäsion und das Verbergen von Informationen. Diese Dinge sind für wiederverwendbaren Code von entscheidender Bedeutung.

Ich würde argumentieren, dass der Hauptvorteil von OOP Modularität und Modifizierbarkeit ist und nicht die Wiederverwendung, aber das ist eine andere Frage.

Objekte ermöglichen eine erneute Code-Ausgabe, sind aber als solche nicht die gängigste Technik. Ich denke, die Wiederverwendung von Code wird durch objektbezogene Techniken wie Vererbung, Polymorphismus, Überladung und Vorlagen gefördert.

Ja, sie tun es. Die Fähigkeit, von einer Superklasse zu erben, trägt zur Wiederverwendung von Code bei. Ich bin mir nicht sicher, wie jemand anders argumentieren könnte. Sie können einfach eine Klasse erweitern und eine Methode überschreiben, während Sie den Rest der Superklasse verwenden. Wenn dies nicht zur Wiederverwendung von Code beiträgt, weiß ich nicht, was das ist

Wenn ja, haben sie ihr Versprechen zur Wiederverwendung von Code bereits eingelöst? Ja, wenn die mit OOP geschriebenen Programme Designmuster mit Bedacht anwenden. Ansonsten meistens nein. Angesichts der Popularität von nicht-trivialen Großprogrammen, die Adobe-Systeme, Google und andere mit C ++ oder Java oder anderen OOP-Sprachen schreiben, würde ich jedoch sagen, dass OOP noch einen langen Weg vor sich hat, bevor es ausläuft. Diese Zeit wird weitaus besser geeignet sein, diese Frage zu stellen, und könnte dazu beitragen, die Grundlagen für ein neues Paradigma zu schaffen.