Objektorientierter Entwurf (OOD) Teil 3: Qualitätsmodell Wie komme ich zu einem guten Entwurf? Definition: Der beste Entwurf ist derjenige, der über die gesamte Lebenszeit der Software minimale Kosten verursacht. Oder Ein schlechter Entwurf erzeugt hohe Wartungskosten Problematisch wird es immer dann, wenn sich Entwurfsentscheidungen hinsichtlich Qualitätsmerkmalen gegenseitig beeinflussen: Erhöhung der Flexibilität geht häufig einher mit einer Verringerung der Verständlichkeit.

Objektorientierter Entwurf (OOD) Teil 3: Qualitätsmodell Drei Ansätze führen zu einem guten Entwurf: Einsatz von bekannten Prinzipien und Heuristiken, die zu robusten, flexiblen und wieder verwendbaren Entwürfen führen. Die zwei bekanntesten sind: Information hiding (Parnas), auch Kapselung, Abstraktion genannt Geringe Kopplung Verwendung von Metriken, die einen Entwurf aus einem festzulegenden Blickwinkel beurteilen. Dadurch kann die Komplexität verringert und die Verständlichkeit erhöht werden. Die bekannteste ist die Cyclomatische Komplexität (McCabe) Zu guter letzt haben wir natürlich noch die bekannten Entwurfs-Muster (design pattern) Und nicht zu vergessen: Bei mehreren Lösungsalternativen ist die einfachste zu wählen.

Objektorientierter Entwurf (OOD) Qualitätsmodell Beispiel: Ausleihe von Videofilmen. Ziel: Es soll ein System zur Rechnungserstellung entworfen werden. Kunde, Ausleihe und Videofilm werden jeweils durch Klassen modelliert. Dem Kunden sind seine Ausleihen zugeordnet, während jede Ausleihe den ausgeliehenen Videofilm und die Ausleihdauer (in Tagen) kennt. Ein Videofilm hat einen Preiscode, der zusammen mit der Leihdauer den Preis bestimmt. Es gibt Preiscodes für normale Filme, Kinderfilme und neue Filme. Der Preiscode eines Videofilmes kann sich ändern, daher gibt es in der Klasse Videofilm eine Methode setzePreiscode(). 1. Entwurf: Es erscheint sinnvoll, die Erstellung einer kundenspezifischen Rechnung in der Klasse Kunde vorzunehmen und dazu alle erforderlichen Informationen bei den Klassen Ausleihe und Videofilm einzuholen.

Objektorientierter Entwurf (OOD) Qualitätsmodell

Objektorientierter Entwurf (OOD) Qualitätsmodell Diskussion des 1. Entwurfs: Dieses Vorgehen ist ein Verstoß gegen die Regel, unnötige Kopplungen zu vermeiden, siehe Benutz-Beziehung im Klassendiagramm: Auf einem Objekt, das von einer anderen Klasse (Ausleihe) als Resultat eines Methodenaufrufs (holeVideofilm) geliefert wurde, wird eine Methode (ermittlePreis) aufgerufen. Außerdem erscheint es sinnvoll, die Preisberechnung für einen(!) Ausleihvorgang in der Klasse Ausleihe durchzuführen. 2. Entwurf: Die Preisberechnung wird geteilt und sowohl in der Klasse Ausleihe als auch in der Klasse Videofilm durchgeführt. (Diagramme nächste Seite) Diskussion des 2. Entwurfs: Zwischen den Klassen bestehen weniger Kopplung (Kunde weiß nichts mehr von Videofilm) und die Kapselung von Ausleihe und Videofilm wurde verbessert, da die drei get-Methoden (holeAusleihdauer, holeVideofilm, holePreis) entfallen können. Jedoch ist die Berechnung des Rechnungsbetrages nun über drei Klassen „verschmiert“, so dass man drei Klassen betrachten muss, um den Algorithmus vollständig nachvollziehen zu können.

Objektorientierter Entwurf (OOD) Qualitätsmodell

Objektorientierter Entwurf (OOD) Qualitätsmodell Unter Einbeziehung des Design Patterns „State“ (zustandsabhängiges Verhalten in separaten Objekten) wird die Preisberechnung in eine abstrakte Klasse Preis ausgelagert. Fallunterscheidung nach dem Preiscode durch dynamisches Binden.

Objektorientierter Entwurf (OOD) Qualitätsmodell Diskussion des 3. Entwurfs: Diese Lösung ist einfacher (als der 2. Entwurf) um neue Preiscodes zu erweitern, auch Änderungen in der Preisberechnung sind einfacher durch zu führen. Dafür jedoch hat sich die Anzahl der Klassen mehr als verdoppelt und damit hat sich die Verständlichkeit verringert.

Objektorientierter Entwurf (OOD) Qualitätsmodell Schlussfolgerungen: Die Änderungen der Entwürfe von 1 nach 3 dienten der Entkopplung und damit der Änderbarkeit. Jedoch verschlechtert sich die Verständlichkeit dadurch, dass die Anzahl der Klassen ansteigt. Es wird Flexibilität eingebaut, die aber nur dann wirklich sinnvoll ist, wenn sich die Preiscodes tatsächlich ändern werden. Die Güte des Entwurfs hängt somit auch vom Kontext der Software ab. Empfehlung: Grundsätze wie Entkopplung und Kapselung von Details und von (sich wahrscheinlich ändernden) Entwurfsentscheidungen sollten immer beachtet werden. Flexibilität, insbesondere durch Entwurfsmuster (design pattern) ist oft teuer, da der vorhandene Entwurf geändert werden muss, und sollte erst dann eingebaut werden, wenn sie benötigt wird.