Offen-geschlossen-Prinzip und Java-Modifikator "final"

Question

Das Open-Closed-Prinzip besagt, dass "Software-Entitäten (Klassen, Module, Funktionen usw.) zur Erweiterung geöffnet, aber zur Änderung geschlossen" sein sollten.

Allerdings gibt Joshua Bloch in seinem berühmten Buch "Effective Java" den folgenden Rat: "Design und Dokument für die Vererbung, oder verbieten es" und ermutigt Programmierer den "finalen" Modifikator zu verwenden, um Unterklassen zu verbieten.

Ich denke, diese beiden Prinzipien widersprechen sich eindeutig (liege ich falsch?). Welchen Grundsatz befolgen Sie beim Schreiben Ihres Codes und warum? Lassen Sie Ihre Klassen offen, verbieten Sie Vererbung bei einigen von ihnen (welche?), Oder verwenden Sie den letzten Modifikator wann immer möglich?

Answer 1

Offen gesagt denke ich, dass das offene/geschlossene Prinzip eher ein Anachronismus ist als nicht. Es stammt aus den 80er und 90er Jahren, als OO-Frameworks auf dem Prinzip aufgebaut wurden, dass alles von etwas anderem erben muss und dass alles unterklassierbar sein sollte.

Dies wurde am häufigsten in UI-Frameworks der Ära wie MFC und Java Swing typisiert. In Swing haben Sie eine lächerliche Vererbung, bei der (iirc) die Schaltfläche checkbox (oder andersherum) erweitert wird und eines davon nicht verwendet wird (ich denke, es ist das setDisabled() -Aufruf-Kontrollkästchen). Warum teilen sie eine Abstammung? Kein Grund außer, nun, sie hatten einige Methoden gemeinsam.

Heutzutage ist die Zusammensetzung der Vererbung vorzuziehen. Während Java die Vererbung standardmäßig zuließ, nahm .Net den (moderneren) Ansatz, es standardmäßig zu verbieten, was ich für korrekter halte (und konsequenter mit den Prinzipien von Josh Bloch).

DI/IoC haben auch für die Zusammensetzung weiter den Fall gemacht.

Josh Bloch weist auch darauf hin, dass Vererbung Einkapselung bricht und gibt einige gute Beispiele dafür. Es wurde auch gezeigt, dass das Ändern des Verhaltens von Java-Sammlungen konsistenter ist, wenn es durch Delegieren erfolgt, anstatt die Klassen zu erweitern.

Persönlich betrachte ich Vererbung in diesen Tagen als wenig mehr als ein Implementierungsdetail.

Answer 2

Ich glaube nicht, dass die beiden Aussagen sich widersprechen. Ein Typ kann zur Erweiterung geöffnet sein und dennoch zur Vererbung geschlossen sein.

Eine Möglichkeit, dies zu tun, ist die Abhängigkeitsinjektion. Anstatt Instanzen eigener Hilfstypen zu erstellen, kann ein Typ diese bei der Erstellung angeben. Dies ermöglicht es Ihnen, die Teile des Typs zu ändern (d. H. Offen für die Erweiterung), ohne den Typ selbst zu ändern (d. H. Für die Modifikation zu schließen).

Answer 3

In (offen für Erweiterung, geschlossen für Änderung) können Sie noch den letzten Modifikator verwenden. Hier ein Beispiel:

public final class ClosedClass { 

    private IMyExtension myExtension; 

    public ClosedClass(IMyExtension myExtension) 
    { 
     this.myExtension = myExtension; 
    } 

    // methods that use the IMyExtension object 

} 

public interface IMyExtension { 
    public void doStuff(); 
} 

Die ClosedClass wird für die Modifikation innerhalb der Klasse geschlossen, sondern offen für die Verlängerung durch einen anderen. In diesem Fall kann es alles sein, was die IMyExtension Schnittstelle implementiert. Dieser Trick ist eine Variation der Abhängigkeitsinjektion, da wir die geschlossene Klasse durch einen anderen, in diesem Fall den Konstruktor, speisen. Da die Erweiterung ein interface ist, kann es nicht final sein, aber seine implementierende Klasse kann sein.

Die Verwendung von final für Klassen, um sie in Java zu schließen, ähnelt der Verwendung von sealed in C#. Es gibt similar discussions darüber auf der .NET-Seite.

Answer 4

Ich respektiere Joshua Bloch sehr viel, und ich halte Effective Java ziemlich das Java Bibel sein. Aber ich denke, dass der automatische Zugriff auf private oft ein Fehler ist. Ich neige dazu, die Dinge protected standardmäßig so zu machen, dass sie mindestens durch Erweiterung der Klasse zugegriffen werden können. Dies ergab sich meist aus der Notwendigkeit, Testkomponenten zu vereinigen, aber ich finde es auch praktisch, das Standardverhalten von Klassen zu überschreiben. Ich finde es sehr ärgerlich, wenn ich in der Codebasis meiner eigenen Firma arbeite und am Ende & die Quelle ändern muss, weil der Autor alles "versteckt" hat. Wenn es überhaupt in meiner Macht ist, lobby ich, um den Zugang zu protected geändert zu haben, um die Verdoppelung zu vermeiden, die IMHO viel schlechter ist.

Denken Sie auch daran, dass Blochs Hintergrund sehrÖffentlichkeit ist Fundament API-Bibliotheken in der Gestaltung; die Leiste, um solchen Code "richtig" zu bekommen, muss sehr hoch gesetzt werden, also ist es wahrscheinlich nicht die gleiche Situation wie der meiste Code, den Sie schreiben werden. Wichtige Bibliotheken wie die JRE selbst neigen dazu, restriktiver zu sein, um sicherzustellen, dass die Sprache nicht missbraucht wird. Sehen Sie alle veralteten APIs in der JRE? Es ist fast unmöglich, sie zu ändern oder zu entfernen. Ihre Codebasis ist wahrscheinlich nicht in Stein gemeißelt, so dass Sie tun die Möglichkeit haben, Dinge zu beheben, wenn sich herausstellt, dass Sie zunächst einen Fehler gemacht haben.

Answer 5

Heutzutage verwende ich den letzten Modifikator standardmäßig fast reflexiv als Teil des Boilerplate. Es macht die Dinge leichter zu verstehen, wenn Sie wissen, dass eine bestimmte Methode immer so funktioniert, wie Sie sie gerade im Code sehen.

Natürlich gibt es manchmal Situationen, in denen eine Klassenhierarchie genau das ist, was Sie wollen, und es wäre albern, sie nicht zu verwenden. Aber fürchten Sie sich vor Hierarchien von mehr als zwei Ebenen oder solchen, bei denen nicht abstrakte Klassen weiter unterklassifiziert werden. Eine Klasse sollte entweder abstrakt oder endgültig sein.

Die meiste Zeit, mit der Zusammensetzung ist der Weg zu gehen. Setze alle üblichen Maschinen in eine Klasse, lege die verschiedenen Fälle in verschiedene Klassen, dann setze Instanzen zusammen, damit sie ganz funktionieren.

Sie können diese "Abhängigkeitsinjektion" oder "Strategie-Muster" oder "Besucher-Muster" oder was auch immer nennen, aber was es kocht, ist die Verwendung von Komposition statt Vererbung, um Wiederholungen zu vermeiden.

Answer 6

Die beiden Aussagen

Software Entitäten (Klassen, Module, Funktionen, usw.) sollten für Erweiterung offen sein, aber für die Änderung geschlossen.

und

Entwurf und Dokument für die Vererbung oder aber es verbieten.

sind nicht in direktem Widerspruch zueinander. Sie können dem Prinzip "offen-geschlossen" folgen, solange Sie es entwerfen und dokumentieren (wie von Bloch empfohlen).

Ich glaube nicht, dass Bloch besagt, dass Sie sollten bevorzugen Erbe zu verbieten, indem die endgültige Modifier, nur, dass Sie explizit in jedem Klassenvererbung zu erlauben oder zu verbieten wählen sollten Sie erstellen.Sein Rat ist, dass Sie darüber nachdenken und für sich selbst entscheiden sollten, anstatt nur das Standardverhalten des Compilers zu akzeptieren.

Answer 7

Ich glaube nicht, dass das Open/Closed-Prinzip, wie es ursprünglich vorgestellt wurde, die Interpretation ermöglicht, dass finale Klassen durch Injektion von Abhängigkeiten erweitert werden können.

In meinem Verständnis geht es beim Prinzip darum, keine direkten Änderungen an Code zuzulassen, der in Produktion gebracht wurde, und die Möglichkeit, Implementierungsvererbung zu verwenden, während man noch Funktionsmodifikationen zulässt.

Wie in der ersten Antwort darauf hingewiesen, hat dies historische Wurzeln. Vor Jahrzehnten gab es eine Vererbung, Entwickler-Tests gab es nicht, und die Neukompilierung der Codebasis dauerte oft zu lange. Beachten Sie auch, dass in C++ die Implementierungsdetails einer Klasse (insbesondere private Felder) häufig in der Header-Datei ".h" offen gelegt wurden. Wenn ein Programmierer dies ändern müsste, müssten alle Clients neu kompiliert werden. Beachten Sie, dass dies bei modernen Sprachen wie Java oder C# nicht der Fall ist. Außerdem glaube ich nicht, dass Entwickler damals auf ausgefeilte IDEs zurückgreifen konnten, die in der Lage waren, eine Abhängigkeitsanalyse direkt durchzuführen, wodurch die Notwendigkeit häufiger vollständiger Neuerstellungen vermieden wurde.

In meiner eigenen Erfahrung, bevorzuge ich das genaue Gegenteil: "Klassen sollten für Erweiterung (final) standardmäßig geschlossen werden, aber offen für die Änderung". Denken Sie darüber nach: Heute bevorzugen wir Praktiken wie Versionskontrolle (macht es einfach, frühere Versionen einer Klasse wiederherzustellen/zu vergleichen), refactoring (was uns ermutigt, Code zu ändern, um Design zu verbessern, oder als Auftakt zur Einführung neuer Funktionen) und Entwicklertest, der ein Sicherheitsnetz bietet, wenn der vorhandene Code geändert wird.