Open Closed Principle (OCP) – Wissenshäppchen #4

Mein viertes Wissenshäppchen hat das Open Closed
Principle zum Thema.
Inhalt

Das OCP ist das zweite der SOLID-Prinzipien. Es wurde vor Robert
„Uncle Bob“ Martin bereits 1988 von Bertrand Meyer definiert:


Software entities (classes, modules, functions, etc.) should be
open for extension, but closed for modification.


Ursprünglich ging es darum, durch Vererbung die Anpassung
(„modification“) bereits bestehender Klassen zu verhindern, indem
Subklassen abgeleitet werden, die die vorhandene Funktionalität
erweitern („extension“). Heutzutage ist Vererbung aber eher nicht
mehr so gerne gesehen, da es eine starke Kopplung an die
Basisklasse zur Folge hat, was das Design inflexibel macht.
Stattdessen sollte man besser von vornherein Interfaces mit
potentiell verschiedenen Implementierungen einsetzen.
Erklärung

Bei Änderungen an einem Programm sollen bestehende
Komponenten bestenfalls gar nicht angepasst werden müssen, da
diese Anpassungen Fehler nach sich ziehen können, die auch das
bereits bestehende Verhalten betreffen.

Neue Funktionalität wird dem Programm immer durch neue
Komponenten hinzugefügt, also z.B. indem neue Klassen oder
Methoden ergänzt werden.

Fallunterscheidungen auf Basis von Typen (z.B. mit instanceof
in Java) oder Enumerations (insb. wenn diese in einem switch
verwendet werden) sind oft ein Hinweis auf Verletzung des OCP und
sollten durch Polymorphie ersetzt werden.

Beispiel class Manager end class Developer end class Payroll
def self.calculate_bonus(employee) if employee.is_a?(Manager)
return 1000 end if employee.is_a?(Developer) return 500 end end end
puts Payroll.calculate_bonus(Manager.new) # 1000 puts
Payroll.calculate_bonus(Developer.new) #500

Wenn diese Bonusberechnung um einen neuen Mitarbeitertyp
Administrator erweitert werden soll, muss die bestehende
Implementierung von calculate_bonus() angepasst werden:
def self.calculate_bonus(employee) if employee.is_a?(Manager)
return 1000 end if employee.is_a?(Developer) return 500 end if
employee.is_a?(Administrator) return 250 end end

Stattdessen sollte von Anfang an die Berechnung des Bonuses an
die Mitarbeiterklassen delegiert werden.
class Manager def bonus 1000 end end class Developer def bonus
500 end end class Payroll def self.calculate_bonus(employee)
employee.bonus end end puts Payroll.calculate_bonus(Manager.new) #
1000 puts Payroll.calculate_bonus(Developer.new) # 500

Dadurch ist eine spätere Erweiterung um neue Mitarbeitertypen
ohne Anpassung des bisherigen Codes möglich:
class Administrator def bonus 250 end end puts
Payroll.calculate_bonus(Administrator.new) # 250

In dynamisch typisierten Sprachen (wie im Beispiel Ruby) ist das
OCP übrigens meist noch einfacher umzusetzen als in statisch
typisierten, da durch das Duck-Typing umfangreiche
Klassenhierarchien oder Interfaces unnötig werden. Dies sieht man
auch im Beispiel oben: Manager und Developer haben keinerlei
Beziehung zueinander. Trotzdem funktioniert der Code, da beide
Klassen die Methode bonus() anbieten.
Vorteile

Bei Erweiterungen der Funktionalität sinkt die
Wahrscheinlichkeit, Fehler in den bereits funktionierenden Code
einzubauen.

Klassen behalten ihre Aufgabe „ein Leben lang“. Abhängige
Klassen können sich darauf verlassen, dass sich die
Funktionalität nicht ändert.

Erweiterungen sind ggfs. einfacher zu implementieren, da
nicht an mehreren Stellen Code angepasst, sondern „nur“ neuer
Code geschrieben werden muss.

Nachteile

Meist ist gar nicht im Voraus bekannt, welche Stellen im Code
später einmal erweitert werden müssen. Einfach nur noch mit
Abstraktionen zu arbeiten, macht den Code aber schwer
verständlich. Außerdem verletzten wir damit das YAGNI-Prinzip.

Literaturempfehlungen

Da Uncle Bob die SOLID-Prinzipien so schön aufgeschrieben hat,
kann ich wieder einmal seinen Klassiker Clean Code* empfehlen.


*
Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Open Closed Principle

ArticleS.UncleBob.PrinciplesOfOod (Artikel von Uncle Bob,
Beispiel in C++)

Open-Closed-Prinzip – Wikipedia

SOLID – Das Open Closed Principle | Informatik Aktuell
(ausführliche Diskussion der Nachteile, Beispiel in C#)

SOLID Design Principles Explained – The Open/Closed Principle
with Code Examples (Beispiel in Java)