Sign up to save your podcasts
Or
Share Open Closed Principle (OCP) – Wissenshäppchen #4
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
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
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
Nachteile
Literaturempfehlungen
Da Uncle Bob die SOLID-Prinzipien so schön aufgeschrieben hat, kann ich wieder einmal seinen Klassiker Clean Code* empfehlen.
*
Links
View all episodes
By Stefan Macke
5
11 ratings
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
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
Nachteile
Literaturempfehlungen
Da Uncle Bob die SOLID-Prinzipien so schön aufgeschrieben hat, kann ich wieder einmal seinen Klassiker Clean Code* empfehlen.
*
Links
More shows like IT-Berufe-Podcast
View all
Streitkräfte und Strategien
45 Listeners
Sternengeschichten
45 Listeners
Geschichten aus der Geschichte
196 Listeners
c’t uplink - der IT-Podcast aus Nerdistan
6 Listeners
MORD AUF EX
128 Listeners
{ungeskriptet} - Gespräche, die dich weiter bringen
23 Listeners