OpenClosed-Principle
Beim OpenClosed-Principle sollen Komponenten offen für Erweiterungen, jedoch geschlossen für Änderungen sein
(Robert C. Martin)
Bei Erweiterungen von Komponenten soll bereits vorhandener Quellcode wenig bis gar nicht geändert werden müssen. Dabei ist es egal ob man als Komponenten Klassen, Pakte oder andere Strukturen meint. OCP stellt sicher, dass zukünftige Anforderungen keine Nebenwirkung verursachen. Da der bereits funktionierende Code ohne Veränderung weiterhin besteht, werden alle Komponenten die ihn benutzen genauso arbeiten wie bisher.
Schlechtes Beispiel
void drive(Vehicle vehicle)
{
…
if (vehicle.Type == car)
driveCar(vehicle);
else if (vehicle.Type == bike)
driveBike(vehicle);
…
}
Hierbei wird über verschachtelte Abfragen die eigentliche Bewegung des Fahrzeugs ausgeführt. Aber was passiert wenn zusätzliche Fahrzeuge aufgenommen werden müssen? Angenommen es kommen noch die Fahrzeuge Truck oder Bagger hinzu. Es wären Anpassungen im bereits laufendem Code notwendig mit entsprechenden Auswirkungen. Diese fallen meistens in Form von Abstürzen und oft erst beim Kunden auf.
Abhilfe
Möglichkeit 1)
Nebenstehendes Bild zeigt eine sinnvolle Modellierung über Schnittstellen dar. Das „fahren“ der Fahrzeuge wird jetzt über die Schnittstelle IVehicle realisiert.
Dabei implementieren alle Fahrzeugklassen dieses Interface. Der Aufrufer ist jetzt nur noch vom Interface abhängig und kennt die Klassen der Fahrzeuge nicht.
Möglichkeit 2)
Eine weitere Möglichkeit ist das Überschreiben von Methoden. Dabei bleibt die Superklasse unverändert, während die Unterklasse mit einzelnen überschriebenen Methoden umgesetzt wird.
Diese Art der Programmierung nutzt den sogenannten Polymorphismus (Vielgestaltigkeit)
Klassendiagramm über Plant UML Editor:
@startuml Interface IVehicle IVehicle : drive()
IVehicle <|.. Skateboard
IVehicle <|.. Bike IVehicle <|.. Car IVehicle <|.. Truck IVehicle <|.. Dredge @enduml
Vorteile
Vermeidung von Seiteneffekten
Stabilisierung des Softwareentwurfs
Nachteile
Einfachheit des Codes geht verloren (u.U)
Höherer Abstraktionsgrad bei der Umsetzung
Sonstiges
Es gibt viele Design Patterns die uns dabei helfen Code zu erweitern ohne viele Änderungen durchzuführen. So hilft uns das Decorator Pattern das OpenClosed-Principle einzuhalten. Ähnliches gilt für das Factory-Pattern oder das Observer-Pattern. Auch hier kann eine Applikation entwickelt werden die einfach und mit minimalem Aufwand Änderungen am bestehenden Code zuläßt.