Frage

Die Open / Geschlossen-Prinzip besagt, dass Software-Entitäten (Klassen, Module, etc.) sollten für Erweiterung offen sein, aber für die Änderung geschlossen. Was bedeutet das, und warum ist es ein wichtiges Prinzip der guten objektorientiertes Design?

War es hilfreich?

Lösung

Im Einzelnen handelt es sich um einen „Heiligen Gral“ der Entwurf in OOP eines Unternehmens ausreichend dehnbar zu machen (durch seine individuelle Gestaltung oder durch seine Teilnahme an der Architektur) ohne zu Umschreiben seinen Code Zukunft unforseen Änderungen zu unterstützen (und manchmal sogar ohne Neukompilierung **).

Einige Möglichkeiten, dies zu tun Polymorphism / Vererbung umfassen, Komposition, Inversion of Control (aka DIP), Aspect-Oriented Programming, Patterns wie Strategie, Besucher, Template-Methode, und viele andere Prinzipien, Muster und Techniken der OOAD.

** Siehe 6 "-Paket Prinzipien", REP, CCP, CRP, ADP, SDP, SAP

Andere Tipps

Es bedeutet, dass Sie neuen Code in neuen Klassen / Module setzen sollte. Bestehende Code sollte nur für Bugfixing modifiziert werden. Neue Klassen wiederverwenden können Code durch Vererbung vorhanden.

offen / geschlossen Prinzip soll Risiko mindern, wenn neue Funktionalitäten einzuführen. Da Sie vorhandenen Code nicht ändern können Sie sicher sein, dass sie nicht gebrochen werden würde. Es Wartungskosten senken und die Produktstabilität erhöhen.

Es ist die Antwort auf das fragile Basisklasse Problem, das sagt, dass scheinbar harmlose Änderungen an Basisklassen unbeabsichtigte Folgen zu Erben haben können, die auf dem bisherigen Verhalten abhing. Also muss man vorsichtig sein, zu kapseln, was Sie nicht wollen, verließ sich auf, so dass die abgeleiteten Klassen, die Verträge von der Basisklasse definiert gehorchen. Und wenn Erben vorhanden sind, müssen Sie auf wirklich vorsichtig mit dem, was Sie in der Basisklasse ändern.

Insbesondere als Davek, bedeutet dies in der Regel, dass, wenn Sie zusätzliche Funktionen hinzufügen möchten, oder die Funktionalität einer Klasse ändern, eine Unterklasse erstellen, anstatt das Original zu verändern. Auf diese Weise kann jeder die Eltern-Klasse muss sich darüber keine Sorgen später ändern. Im Grunde geht es um die Abwärtskompatibilität.

Ein weiteres wirklich wichtiges Prinzip der objektorientierten Design ist lose Kopplung durch ein Verfahren Schnittstelle. Wenn die Änderung, die Sie machen wollen nicht die bestehende Schnittstelle beeinflussen, es ist wirklich ziemlich sicher zu ändern. Zum Beispiel wird ein Algorithmus effizienter zu machen. Objektorientierte Prinzipien müssen durch den gesunden Menschenverstand zu temperiert werden:)

  

Software Einrichtungen sollten für Erweiterung offen sein, aber für die Änderung geschlossen

Das bedeutet, dass jede Klasse oder Modul sollte so geschrieben sein, dass sie verwendet werden kann, wie es ist, kann erweitert werden, aber Neve modifiziert

Bad Beispiel in Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Wenn Sie einen anderen Saft Typ hinzufügen möchten, müssen Sie das Modul selbst, durch diese Art und Weise bearbeiten, wir brechen OCP.

Gutes Beispiel in Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Jetzt können Sie neue Saft Typen von außerhalb des Moduls hinzugefügt werden, ohne das gleiche Modul zu bearbeiten.

Das Prinzip bedeutet, dass es sollte einfach neue Funktionen hinzuzufügen, ohne die bestehenden, stabilen ändern zu müssen und getestet Funktionalität, spart Zeit und Geld.

Oft polymorhism, zum Beispiel mit Hilfe von Schnittstellen, ist ein gutes Werkzeug, um dies zu erreichen.

Eine weitere Faustregel gilt: OCP zur Anpassung ist auf Basisklassen abstrakt in Bezug auf Funktionalität, die von abgeleiteten Klassen zur Verfügung gestellt werden. Oder wie Scott Meyers sagt ‚Make Non-Blatt Klassen abstrakt‘.

Das bedeutet nicht implementierten Methoden in der Basisklasse mit und nur diese Methoden in Klassen implementieren, die selbst keine Unterklassen haben. Dann wird der Kunde von der Basisklasse kann nicht auf eine bestimmte Implementierung in der Basisklasse verlassen, da es keine gibt.

Ich möchte nur betonen, dass „Open / Closed“, obwohl in der OO-Programmierung offensichtlich nützlich sein, eine gesunde Methode ist in allen Aspekten der Entwicklung zu nutzen. Zum Beispiel in meiner eigenen Erfahrung ist es ein großes Schmerzmittel „Open / Closed“ so viel wie möglich zu verwenden, wenn mit einfacher C arbeiten.

/ Robert

Das bedeutet, dass die OO-Software auf gebaut werden sollte, aber nicht an sich verändert. Das ist gut, weil es zuverlässige, vorhersagbare Leistung von den Basisklassen gewährleistet.

Ich habe vor kurzem gegeben wurde, eine zusätzliche Vorstellung davon, was dieses Prinzip bringt., Dass die Open-Geschlossen-Prinzip auf einmal eine Art und Weise des Schreibens Code beschreibt, sowie eine End-Ergebnis des Schreibens Code in einer elastischen Art und Weise

Ich mag Open denken / Geschlossen aufgeteilt in zwei eng miteinander verbundenen Teilen:

  • Code, ist Öffnen können entweder ändern ihr Verhalten ändern richtig an seine Eingänge zu verarbeiten, oder erfordert minimale Änderung für neue Nutzungsszenarien zu schaffen.
  • Code, ist geschlossen für die Änderung erfordert nicht viel, wenn ein menschlicher Eingriff neue Nutzungsszenarien zu behandeln. Die Notwendigkeit, einfach nicht vorhanden ist.

So Code, der Offen / Geschlossen-Verhalten zeigt (oder, wenn man will, erfüllt die Open / Geschlossen-Prinzip) erfordert nur eine minimale oder keine Änderung in Reaktion auf Nutzungsszenarien jenseits dessen, was es wurde ursprünglich gebaut.

Was die Umsetzung betrifft? Ich finde, dass die häufig genannte Interpretation, „Open / Closed zu Code bezieht sich polymorph zu sein!“ bestenfalls eine unvollständige Aussage zu sein. Polymorphismus in Code ist ein Werkzeug, um diese Art von Verhalten zu erreichen; Vererbung, Implementierung ... wirklich, jede objektorientierte Design-Prinzip ist notwendig, Code zu schreiben, in der Art und Weise impliziert dieses Prinzip elastisch ist.

Konstruktionsprinzip, FEST -. Das "O" in "SOLID" steht für das offene / geschlossene Prinzip

Offen Geschlossen Prinzip ist ein Konstruktionsprinzip, das besagt, dass eine Klasse, Module und Funktionen sollten für Erweiterung offen sein, aber für die Änderung geschlossen.

Dieses Prinzip besagt, dass das Design und das Schreiben des Codes sollte, sollten Mindest Änderungen in den bestehenden Code (getestet Code) hinzugefügt werden, in einer Weise, die neue Funktionalität erfolgen. Das Design sollte in einer Weise geschehen, die das Hinzufügen neuer Funktionen als neue Klassen zu ermöglichen, halten so viel wie möglich vorhandenen Code unverändert.

Nutzen von Open Closed Prinzip:

  1. Die Anwendung wird robuster sein, weil wir nicht bereits getestet Klasse ändern.
  2. Flexible, weil wir einfach neue Anforderungen aufnehmen können.
  3. Einfach zu testen und weniger fehleranfällig.

Meine Blog-Post auf diese:

http://javaexplorer03.blogspot.in/2016 /12/open-closed-design-principle.html

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top