Veränderung kapseln

Eine Konstante in der Softwareentwicklung, egal wo, was oder in welcher Programmiersprache man entwickelt: Veränderung. Es ist eigentlich egal, wie gut man eine Anwendung entworfen hat. Im Lauf der Zeit wird sie wachsen und sich wandeln müssen.

Für die Wartung und Wiederverwendung von Elementen/Klassen einer Anwendung ist es besser, wenn nicht versucht wird, alles über Vererbung zu lösen. Wird stur vererbt, kann es schnell bei einer lokalen Änderung zu weitreichenden Seiteneffekten kommen. Dazu bietet sich das einfach Beispiel aus dem Buch “Entwurfsmuster von Kopf bis Fuß” an :) .

In einer Entensimulation gibt es die Superklasse Ente, die die Methoden quacken und schwimmen für alle Sub-Enten implementiert. Eine abtrakte Methode anzeigen wird von den Sub-Enten implementiert, um sich selbt darzustellen.

Nun sollen die Enten fliegen können.

Eine Möglichkeit per Vererbung packt die Methode fliegen direkt in die Superklasse Ente. Nur jetzt können z.B. auch Enten fliegen, die es gar nicht sollten, wie eine Gummiente. Wenn nun alle Enten die Methode fliegen überschreiben und praktisch leer implementieren, dann wäre das Problem gelöst, aber bei jeder neuen Ente muss man beachten, ob sie fliegen kann oder nicht.

Eine weitere Möglichkeit wäre die Verwendung eines FlugFähig-Interfaces, das nur von den Enten implementiert wird, die auch tatsächlich fliegen können. Allerdings wird dann Code verdoppelt, da alle fugfähigen Enten das Interface implementieren müssen. Ein Wartungsalptraum ;) .

Da also die Vererbung nicht der Weisheit letzer Schluss ist, kommt man zu folgendem Entwurfsprinzip:

Identifizieren der Aspekte, die sich ändern können und sie von denen trennen, die konstant bleiben.

In obigem Entenbeispiel wird die fliegen Methode in ein Interface herausgezogen und verschiedene Flugverhalten implementiert (z.B. “normales” fliegen und “nicht” fliegen). Jeder Ente wird nun eins der Flugverhalten-Implementierungen übergeben, das zu ihr passt.

Die unterschiedlichen Flugverhalten sind nun nur noch 1x implementiert und werden den Enten “aufgesteckt”. Das fördert Code-Wiederverwendung und die Änderung an einem Flugverhalten stört keine Enten, die ein anderes Flugverhalten haben.

Wie das konkret im Quellcode aussieht, gibts im nächsten Teil über Programmieren auf eine Schnittstelle.

Literatur

  • FREEMAN, E und FREEMAN, E: Entwurfsmuster von Kopf bis Fuß. O’Reilly, 2006.

Leave a Reply