Objektorientierte Programmierung: Teil 4 – Strategie, wechsel Dich!
Abhängigkeiten
Es gibt nun zwar mehr Abhängigkeiten, aber es handelt sich dabei immer nur um zusätzliche Abhängigkeiten zu einem Interface, welche sehr leichtgewichtig sind.
Ebenso sind durch die Ersetzung von IStrategy durch die Basisklasse BaseStrategy keine neuen Abhängigkeiten entstanden.
Vor- und Nachteile
Nachteile ergeben sich keine aus der Lösung. Der Vorteil ist, dass die Strategien nun ineinader wechseln können und diese vor allem bei komplexeren Strategien wieder verwendbar sind.
Implementierung
Die potentielle zyklische Abhängigkeit von IStrategyContext zu BaseStrategy lässt sich leicht durch Vorwärtsdeklarationen lösen. Man kann in C++ sogar noch einen Schritt weitergehen und in BaseStrategy mit einer Vorwärtsdeklaration auf IStrategyContext auskommen. Der Grund ist, dass BaseStrategy das Interface nie selbst nutzt, sondern nur verwaltet. Und dafür muss es nur den Namen kennen, nicht den eigentlichen Code, der dahintersteckt.
Die C++-Implementierung der obigen Klassen kann als Archiv heruntergeladen werden: oop7-beispiel.tar.gz.
Abschluss
Die vier Teile zur objektorientierten Programmierung sollten einen kleinen Einblick geben, wie man aus einem einfachen Problem etwas designtechnisch extrem kompliziertes machen kann. Natürlich nicht, damit es niemand mehr versteht, sondern damit die Lösung auch für die Zukunft leicht erweiterbar und wartbar ist. Und in der Regel hilft ein gutes Design dem Verständnis.
Wie im ersten Teil erwähnt, gibt es zu einer Aufgabe aber immer mehrere Lösungen. Und so gibt es für das gestellte Problem natürlich auch mehrere Designentscheidungen in die eine oder andere Richtung. Vorrangig sollten in der Reihe aber verschiedene Design-Prinzipien und Entwurfsmuster vorgestellt werden.
Man sollte sich auch im Klaren darüber sein, dass eine sture Entwicklung nach dem Motto »Erst das Design, dann die Implementierung« selten funktioniert. In der Regel erkennt man während der Implementierung, dass man im Design etwas falsch gemacht hat, etwas fehlt oder einfach gar nicht in der benutzten Sprache zu realisieren ist. Daher sollte das Design zwar zuerst entstehen, während der Umsetzung aber iterativ angepasst werden.
Literatur
- E. Gamma, R. Helm, R. Johnson und J. Vlissides: »Design Patterns. Elements of Reusable Object-Oriented Software«, Addison-Wesley 1994, ISBN 978-0201633610
- E. Gamma, R. Helm, R. Johnson und J. Vlissides: »Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software«, Addison-Wesley 2004, ISBN 978-3827321992
- E. & E. Freeman, B. Bates und K. Sierra: »Head First Design Patterns«, O'Reilly Media 2004, ISBN 978-0596007126
- R. C. Martin: »Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code«, mitp-Verlag 2009, ISBN 978-3826655487
Autoreninformation
Dominik Wagenführ (Webseite) ist C++-Software-Entwickler und hat täglich mit Software-Design zu tun. Dabei muss er sich immer Gedanken machen, dass seine Software auch in Zukunft einfach wartbar und leicht erweiterbar bleibt.
Dieser Artikel ist in freiesMagazin 06/2012 (ISSN 1867-7991) erschienen. Veröffentlichung mit freundlicher Genehmigung.
