Klären Sie das offene / geschlossene Prinzip

Wie ich es erklärt habe, besagt das Open / Closed-Prinzip, dass einmal geschriebener Code nicht geändert werden sollte (abgesehen von Fehlerkorrekturen). Aber wenn sich meine Geschäftsregeln ändern, sollte ich dann nicht den Code ändern, der diese Änderungen implementiert? Ich vermute, ich verstehe etwas nicht über das Prinzip, weil es für mich keinen Sinn ergibt.

Dies ist wahrscheinlich das am schwierigsten zu erklärende solide Prinzip. Lass es mich versuchen. Stellen Sie sich vor, Sie haben eine Invoice-Klasse geschrieben, die perfekt funktioniert und keine Fehler aufweist. Es erstellt ein PDF einer Rechnung.

Dann sagt jemand, sie wollen eine HTML-Rechnung mit Links. Sie ändern keinen Code in Invoice, um diese Anforderung zu erfüllen. Stattdessen erstellen Sie eine andere Klasse, HTMLInvoice, die das tut, was sie jetzt wollen. Sie nutzen die Vererbung, damit Sie in HTMLInvoice nicht viel doppelten Code schreiben müssen.

Alter Code, der die alte Rechnung verwendet hat, ist nicht beschädigt oder in irgendeiner Weise betroffen. Der neue Code kann HTMLInvoice verwenden. (Wenn Sie auch Liskov Substitutability , das L von solid, ausführen, können Sie vorhandenen Code, der Rechnungsinstanzen erwartet, mit HTMLInvoice-Instanzen versehen.) Jeder lebt von nun an glücklich.

Die Rechnung kann nicht geändert oder erweitert werden. Und Sie müssen die Rechnung im Voraus richtig schreiben, damit dies funktioniert, übrigens.

Haben Sie den Artikel The Open-Closed Principle von Onkel Bobs Freunden bei ObjectMentor gelesen? Ich denke, es ist eine der besseren Erklärungen da draußen.

Es gibt viele Heuristiken, die mit objektorientiertem Design verbunden sind. Beispiel: "Alle Mitgliedsvariablen sollten privat sein", "Globale Variablen sollten vermieden werden" oder "Die Verwendung der RTTI (Runtime Type Identification) ist gefährlich". Woher stammen diese Heuristiken? Was macht sie wahr? Sind sie immer wahr Diese Kolumne untersucht das Designprinzip, das diesen Heuristiken zugrunde liegt - das Open-Closed-Prinzip.

Wie Ivar Jacobson sagte: „Alle Systeme ändern sich während ihres Lebenszyklus. Dies muss berücksichtigt werden, wenn Systeme entwickelt werden, die voraussichtlich länger als die erste Version halten. “Wie können wir Designs erstellen, die angesichts von Änderungen stabil sind und die länger als die erste Version halten werden? Bertrand Meyer gab uns bereits 1988 Orientierung, als er das mittlerweile berühmte Open-Closed-Prinzip prägte. Um ihn zu umschreiben:

SOFTWARE-EINHEITEN (KLASSEN, MODULE, FUNKTIONEN usw.) SOLLTEN ZUR ERWEITERUNG GEÖFFNET, ABER ZUR ÄNDERUNG GESCHLOSSEN WERDEN.

Wenn eine einzelne Änderung an einem Programm zu einer Kaskade von Änderungen an abhängigen Modulen führt, weist dieses Programm die unerwünschten Attribute auf, die wir mit „schlechtem“ Design assoziieren. Das Programm wird zerbrechlich, starr, unvorhersehbar und nicht wiederverwendbar. Das Open-Closed-Prinzip greift dies auf sehr einfache Weise an. Es heißt, dass Sie Module entwerfen sollten, die sich nie ändern . Wenn sich die Anforderungen ändern, erweitern Sie das Verhalten solcher Module, indem Sie neuen Code hinzufügen und nicht indem Sie alten Code ändern, der bereits funktioniert.

Beschreibung

Module, die dem Open-Closed-Prinzip entsprechen, weisen zwei Hauptattribute auf.

1. Sie sind "Open For Extension".
   Dies bedeutet, dass das Verhalten des Moduls erweitert werden kann. Dass wir das Modul auf neue und unterschiedliche Weise dazu bringen können, dass sich die Anforderungen der Anwendung ändern oder die Anforderungen neuer Anwendungen erfüllt werden.
2. Sie sind „wegen Änderungen geschlossen“.
   Der Quellcode eines solchen Moduls ist unverletzt. Niemand darf Änderungen am Quellcode vornehmen.

Es scheint, dass diese beiden Attribute im Widerspruch zueinander stehen. Die normale Art, das Verhalten eines Moduls zu erweitern, besteht darin, Änderungen an diesem Modul vorzunehmen. Es wird normalerweise angenommen, dass ein Modul, das nicht geändert werden kann, ein festes Verhalten aufweist. Wie können diese beiden gegensätzlichen Attribute gelöst werden?

Abstraktion ist der Schlüssel ...

Die Antwort von Kate Gregory ist sehr gut, aber betrachten Sie eine andere Situation, in der eine neue Anforderung durch eine relativ kleine Änderung in der vorhandenen InvoiceKlasse erfüllt werden kann . Angenommen, der Rechnungs-PDF muss ein neues Feld hinzugefügt werden. Laut OCP sollten wir immer noch eine neue Unterklasse erstellen, auch wenn das neue Feld in der vorhandenen Implementierung durch Ändern einiger Codezeilen hinzugefügt werden könnte.

Meines Erachtens spiegelt OCP die Realität der 80er und frühen 90er Jahre wider, in denen Projekte häufig nicht einmal die Versionskontrolle verwendeten, geschweige denn automatisierte Regressionstests oder den Vorteil ausgefeilter Refactoring-Tools hatten. OCP war ein Versuch, das Risiko zu vermeiden, dass manuell getesteter und in die Produktion gebrachter Code beschädigt wird. Heutzutage haben wir bessere Möglichkeiten, um das Risiko von Software-Brüchen zu bewältigen (Versionskontrollsysteme, TDD und automatisierte Tests sowie Refactoring-Tools).

Persönlich denke ich, dass dieses Prinzip mit einer Prise Salz genommen werden sollte. Code ist organisch, Unternehmen ändern sich und Code ändert sich im Laufe der Zeit entsprechend den Anforderungen eines Unternehmens.

Ich finde es sehr schwierig, mir klar zu machen, dass Abstraktion der Schlüssel ist. Was ist, wenn die Abstraktion ursprünglich falsch war? Was ist, wenn sich die Geschäftsfunktion erheblich geändert hat?

Dieses Prinzip stellt im Wesentlichen sicher, dass sich die ORIGINAL Intentionen und das Verhalten eines Designs niemals ändern dürfen. Das funktioniert wahrscheinlich für diejenigen, die öffentliche APIs haben und deren Kunden Probleme haben, mit neuen Releases und einigen anderen Randfällen Schritt zu halten. Wenn ein Unternehmen jedoch den gesamten Code besitzt, stelle ich dieses Prinzip in Frage.

Eine gute Testabdeckung Ihres Codes sollte das Refactoring Ihrer Codebasis zum Kinderspiel machen. Es bedeutet, dass es in Ordnung ist, Fehler zu machen - Ihre Tests helfen Ihnen dabei, ein besseres Design zu finden.

Wenn es keine Tests gibt, dann ist dieses Prinzip vernünftig.