Die Artikelreihe beschäftigt sich mit den seit etwa 10 Jahren bekannten OO-Design-Mustern Robert Martins. Das ist reichlich spät, aber auf jeden Fall der Mühe wert! Dafür ein großes Dankeschön.
Im dritten Teil wird das Open-Close-Principle behandelt: Offen für Erweiterungen und geschlossen für Änderungen. Dieses für Framework- und Library-Entwicklung essentielle Prinzip wird, wie mir scheint, oft missachtet ... und leider auch manchmal missverstanden.
Äußeres Zeichen ist der unsägliche Gebrauch von private und package protected (default visibility) Methoden. Derart deklarierte Methoden lassen sich in externen Packages nicht mehr überschreiben. Die Klasse ist damit funktional nicht erweiterbar, Wiederverwendbarkeit und das Method-Template-Pattern werden ad absurdum geführt.
Ein Beispiel findet sich im Listing 3 des Artikels: Was, wenn in einer von LoginService abgeleiteten Klasse die Methode checkCredentials eine weitere Prüfung durchführen soll? In der vorliegenden Implementierung muss die Methode login neu implementiert werden. Dafür besteht fachlich kein Grund, außerdem sind Probleme für die Wartung absehbar, wenn die Methode login in der übergeordneten Klasse LoginService geändert werden sollte.
Im nicht so seltenen Extremfall führt die exzessive Verwendung von private und package protected Methoden dazu, Wiederverwendung zu verhindern. Wer schon einmal versucht hat, Klassen aus dem Package java.swing.text zu erweitern, weiß, was gemeint ist. Das Package scheint die Sichtbarkeit "protected" nicht zu kennen. Wenn man nicht den Boot-Classpath anpassen will (wo man eigene Klassen im Package java.swing.text definiert, die die Sichtbarkeit von default auf protected erweitern), dann muss man praktisch die gesamte Funktionalität neu implementieren ... Copyright- und Wartungsprobleme bei jedem neuen JDK-Release eingeschlossen.
Also: vertraut euren Kollegen und verwendet mehr "protected"!
Im dritten Teil wird das Open-Close-Principle behandelt: Offen für Erweiterungen und geschlossen für Änderungen. Dieses für Framework- und Library-Entwicklung essentielle Prinzip wird, wie mir scheint, oft missachtet ... und leider auch manchmal missverstanden.
Äußeres Zeichen ist der unsägliche Gebrauch von private und package protected (default visibility) Methoden. Derart deklarierte Methoden lassen sich in externen Packages nicht mehr überschreiben. Die Klasse ist damit funktional nicht erweiterbar, Wiederverwendbarkeit und das Method-Template-Pattern werden ad absurdum geführt.
Ein Beispiel findet sich im Listing 3 des Artikels: Was, wenn in einer von LoginService abgeleiteten Klasse die Methode checkCredentials eine weitere Prüfung durchführen soll? In der vorliegenden Implementierung muss die Methode login neu implementiert werden. Dafür besteht fachlich kein Grund, außerdem sind Probleme für die Wartung absehbar, wenn die Methode login in der übergeordneten Klasse LoginService geändert werden sollte.
Im nicht so seltenen Extremfall führt die exzessive Verwendung von private und package protected Methoden dazu, Wiederverwendung zu verhindern. Wer schon einmal versucht hat, Klassen aus dem Package java.swing.text zu erweitern, weiß, was gemeint ist. Das Package scheint die Sichtbarkeit "protected" nicht zu kennen. Wenn man nicht den Boot-Classpath anpassen will (wo man eigene Klassen im Package java.swing.text definiert, die die Sichtbarkeit von default auf protected erweitern), dann muss man praktisch die gesamte Funktionalität neu implementieren ... Copyright- und Wartungsprobleme bei jedem neuen JDK-Release eingeschlossen.
Also: vertraut euren Kollegen und verwendet mehr "protected"!
Comment