Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt

7.1 Ein Beispiel 75
scheidung nach dem Geheimnisprinzip; Parnas, 1972b). Die zur Berechnung benötigte
Leihdauer muss nun beim Aufruf als Parameter übergeben werden.
Werden die genannten Verbesserungen an Entwurf A umgesetzt, entsteht Entwurf B
(vgl. Abbildung 7-3 und Abbildung 7-4). Im Vergleich zu Entwurf A besteht zwischen
den Klassen weniger Kopplung (Customer weiß nichts mehr von Movie). Die Kapselung
von Movie und Rental wurde ebenfalls verbessert, so dass nun auch die drei get-
Methoden, die von statement vorher benötigt wurden, entfallen können (getPriceCode,
getDaysRented, getMovie). Die Berechnung des Rechnungsbetrags ist stärker dezentralisiert,
so dass das Problem der „God Class“ (Riel, 1996), die den Entwurf dominiert
und alle Funktionalität an sich zieht, vermieden wird. Auf der anderen Seite ist die
Berechnung nun über drei Klassen „verschmiert“, so dass alle drei Klassen betrachtet
werden müssen, um den Algorithmus nachvollziehen zu können. Bei Entwurf A
genügte im Wesentlichen die Betrachtung der Klasse Customer.
Abbildung 7-3: Klassendiagramm für Entwurf B
Abbildung 7-4: Sequenzdiagramm für Entwurf B
Zweite Stufe: State-Muster für Movie
Entwurf C entsteht aus B durch die Anwendung des State-Musters (Gamma et al.,
1995). Die Preisberechnung für einen Film wird in eine abstrakte Klasse Price ausgelagert.
Zu Price gibt es für jeden Preiscode eine konkrete Unterklasse, die in der
Methode getCharge den spezifischen Preis berechnen kann (vgl. Abbildung 7-5). Die
resultierende Kommunikation ist in Abbildung 7-6 dargestellt.
Der Vorteil dieser Lösung ist, dass getCharge in Movie leichter zu implementieren ist,
da die bisher explizit im Code zu formulierende Fallunterscheidung nach dem Preiscode
jetzt durch dynamisches Binden erledigt wird. Die Lösung kann daher einfacher
um neue Preiscodes erweitert werden. Außerdem ist die Preisberechnung für einzelne