Kategorien
Open-Closed-Prinzip
Wieder zurück in der Hansestadt nach einer Woche Urlaub im Schnee. Als erstes möchte ich mich natürlich bei meinen Co-Autoren bedanken, für fünf wirklich gute Artikel. Die Statistiken munkeln sogar so was wie „die beste Woche“ bisher. Also nochmal vielen Dank dafür. Jetzt aber wieder zum Ernst des Lebens … der Softwaretechnik. Leider kann ich bei diesem Artikel nicht aus anderen Quellen zitieren, da ich gerade kein Internet habe, aber ich versuche das mal auf eigene Faust und schreibe wild drauf los.
Im Open-Closed-Prinzip geht es darum, dass man seinen Code immer so schreibt, dass er offen für Erweiterungen (open) ist und geschlossen für Änderungen (closed). Das klingt jetzt vielleicht erstmal paradox. Erweiterungen und Änderungen sind doch eigentlich fast das gleiche oder gehen zumindest Hand in Hand. Deswegen erläutern wir das am besten mal ein wenig genauer. Falls etwas offen für Erweiterungen ist, so kann ich jederzeit neue Funktionalitäten hinzufügen ohne Probleme zu bekommen. Wenn ich diese Funktionalität einsetze, so ist es wichtig, dass ich bestehende Schnittstellen damit nicht beeinträchtige. Es darf sich also nach außen nichts verändern. Ich bin also geschlossen für Änderungen.
Eine Klasse, ein Modul oder ein Service ist also besonders gelungen, falls ich ihn erweitern kann, ohne das Konsumenten diese Erweiterung mitbekommen, sie aber trotzdem bei Bedarf nutzen können. Besonders wichtig ist dieses Prinzip falls man öffentliche Bibliotheken bereitstellt. Stellt euch mal vor, dass das Zend Framework bei jeder Erweiterung Schnittstellen anpassen würde und ihr euren kompletten Code umbauen müsstet, damit er weiterhin funktioniert. Wäre doch echt kacke!
Ich würde mal sagen, dass ich in der nächsten Zeit ein paar Beispiele mitbringen werde, damit wir darüber diskutieren können, wie man dieses Paradigma am effizientesten umsetzt. Bis dahin hoffe ich dem ein oder anderen ein neues Buzzword beigebracht zu haben.
Ich werfe mal das Decorator Muster in den Raum. Passt ziemlich gut dazu, würde ich sagen
Hmm… solange ich eine Schnittstelle erweitere, sagen wir mal, ich brauche einen weiteren Parameter, kann ich den ja so einbinden, dass bestehender Code nicht angepasst werden muss. Würde man das auch unter Erweiterung einordnen?
@Sebastian: Guter Wurf (http://www.phphatesme.com/blog/softwaretechnik/php-entwurfsmuster-decorator/)
@Dennis: Mit optionalen Parametern geht das. Ich finde aber, diese Parameter machen den Code irgendwann unlesbar. In „Clean Code“ wird zum Beispiel beschrieben, dass eine Methode maximal zwei Parameter haben sollte und wird da auch schlüssig erklärt. Ich bekomme es leider nicht mehr 100% zusammen, kann es aber vll. mal nachreichen.
Okay – also es geht um das Erweitern einer Klasse ohne gezwungen zu sein deren Quelltext zu ändern. Also wohl zurück zu den Basics?
Where is the bacon?
@Tom: Das hast du falsch verstanden. Du darfst den Quelltext der Klasse ändern, nur die Nutzer der Klasse sollen ihn nicht ändern müssen.
Das ganze geht auch in Richtung Interfaces. Wenn ich meinen Code immer gegen stabile Interfaces programmiere, werde ich auch dazu erzogen, mir vorher tiefgründige Gedanken über die Funktionen und Parameter zu machen, und diese im späteren Code-Leben nicht verändern zu müssen.
Sollte ich eine Klasse erweitern müssen, kann ich mir überlegen sie entweder gegen ein zweites Interface zu programmieren oder das ursprüngliche Interface zu erweitern.
Wobei die Erweiterung eines vorhandenen Interfaces auch nicht immer ohne weiteres möglich ist.
Das Stichwort „Modularisierung“, auch innerhalb von Klassen im Bereich der Objektorientierung spielt für mich hier auch eine wichtige Rolle, um einfacher in Abläufe eingreifen zu können.