Objektorientiertes Design Clemens Haindl

Inhalt Vererbung & Co. Konsistenz Überladen von Operatoren Frameworks & Entwurfsmuster

Abstraktion Gemeinsame Eigenschaften mehrerer Klassen in einer gemeinsamen Superklasse implementieren Klassen nicht überspezialisieren: Eine Klasse soll eine Menge von Objekten beschreiben Verschiedene Klassen müssen sich in ihrem Verhalten unterscheiden, nicht nur in konstanten Werten. Es ist besser, ein Modell zunächst mit weniger spezialisierten Klassen und virtuellen Methoden zu implementieren und dieses bei Bedarf zu erweitern, als umgekehrt.

Vererbung Die Anwendung von identischen Operationen auf Objekte unterschiedlichen Typs ist kein legitimer Grund für die Erzeugung von Unterklassen zur Behandlung jedes einzelnen Typs. Beispiel: Listen Alternativen: Dynamische Bindung (.NET) bzw. Templates (C++)

Kopplung Die Kopplung ist ein Maß für die gegenseitige Abhängigkeit von Klassen. Je mehr Interaktionen zwischen zwei Klassen stattfinden, desto stärker sind sie aneinander gekoppelt. Unterklassen stehen oft erweiterte Möglichkeiten zur Kopplung an die Superklasse zur Verfügung. Eine Reduktion der Kopplung erhöht i.a. die Les- und Wartbarkeit des Codes.

Folgerungen Auch wenn ein Problem mit Vererbung lösbar ist, existieren möglicherweise bessere Lösungen, die ohne den Einsatz von Vererbung auskommen. …oder allgemeiner: Neue mächtige Features in höheren Sprachen verführen den Programmierer beständig zu ihrem Einsatz, weshalb dieser umso mehr dazu angehalten ist auch herkömmliche Lösungswege nicht außer acht zu lassen.

Inhalt Vererbung & Co. Konsistenz Überladen von Operatoren Frameworks & Entwurfsmuster

Konsistenz - Konstruktoren Default-Werte für Felder auch als solche angeben, und nicht in den default-Konstruktor auslagern. Ein Konstruktor soll ein Objekt in einem wohldefinierten Zustand hinterlassen. Negativ-Beispiel: Nicht initialisierte Felder (besonders Public) bedeuten die ständige Gefahr einer NPE.

Konsistenz - Nachvollziebarkeit Logische vs. physische Sicht Logischer Bereich so intuitiv und Robust wie möglich Physischer Bereich soll trotz Transparenz nachvollziehbar bleiben „Überraschungen“ vermeiden - Beispiel: Zwei überladene Methoden sollen Daten unterschiedlichen Typs in Dateien schreiben. Erwartung: Die Dateien werden im selben Modus geöffnet.

Invarianten Sind Konsistenzbedingungen auf Klassenebene Sollen identifiziert und explizit aufrechterhalten werden. In Klassen mit erhöhter Robustheit empfiehlt sich die Prüfung der Invarianten am Anfang und am Ende jeder Methode (assert) Entsprechen in ihrer Funktion Constraints in relationalen DB-Systemen.

Redundanz Tritt auf, wenn Daten mit der selben Bedeutung an verschiedenen Stellen mehrmals gespeichert werden Identische Codesequenzen mit der selben Aufgabe mehrfach implementiert werden Stellt eine Gefahr für die Konsistenz dar (wie bei relationalen DB-Systemen) Abhilfe: Keine Daten speichern, die nie benötigt werden. Mehrfach benötigte Codesequenzen in Methoden auslagern.

Inhalt Vererbung & Co. Konsistenz Überladen von Operatoren Frameworks & Entwurfsmuster

Allgemeine Regeln Die Bedeutung eines überladenen Operators soll der in der Sprache üblichen Bedeutung entsprechen. Ein überladener Operator muss mit allen anderen vorhandenen Operatoren korrekt interagieren: Vorrangregeln, Kommutativ-, Assoziativ- und Distributivgesetz Konsistenz!

Mögliche Problemquellen Diverse Konvertierungen Mehrdeutige Überladungen Default-Argumente Konstruktoren Vererbung Beispiel: FileArray

Inhalt Vererbung & Co. Konsistenz Überladen von Operatoren Frameworks & Entwurfsmuster

Anno 1996 „It remains unclear how frameworks designed by different teams, probably in different languages, can interoperate.“ .NET-Lösung: CTS und CL-Compiler für möglichst viele Sprachen, Remoting CORBA-Lösung: Language bindings. Ermöglicht plattformunabhängige Interprozesskommunikation The fragile base-class problem might overthrow fundamental network design decisions: changes in base classes of a framework can fracture numerous classes inheriting from them.“ .NET-Lösungsversuch: Versionierung von Assemblies, virtual – new/override Schlüsselwörter

Hot-Spot-Driven Design Methode zur Entwicklung von Frameworks. Ausgangspunkt: Ausgereifte objektorientierte Abstraktion. Basiert auf der Identifizierung und anschließender Flexibilisierung von Hot-Spots im objektorientierten Modell Erfordert domain expert knowledge (Abstraktion)

Identifizierung von Hot-Spots Problem: Kommunikation zwischen Programmierer und domain expert. Hilfreich: Hot-Spot Cards Ermöglichen die Darstellung der Anforderungen an das Framework in einer Form, die sowohl domain expert, als auch der/die Programmierer verstehen können

Beispiel: Hot-Spot Card Hot-Spot Name Erforderliche Flexibilität: Änderung ohne Neustart (Ja/Nein) Änderung durch User (Ja/Nein) Semantische Beschreibung Funktion: Beschreibung des Verhaltens in Beispielsituationen Daten: Beispieldaten

Implementierung - Daten Datenobjekte werden als neue abstrakte Klassen implementiert. Problem 1: Datenobjekte werden schon auf Hot-Spot Cards oft falsch abstrahiert Problem 2: Daten Hot-Spot Cards geben keine direkte Auskunft über die Schnittstelle der abstrakten Klasse. Weitere (domain-spezifische) Informationen sind dafür meist erforderlich.

Implementierung - Funktion Funktionen werden als sog. Hook-Methoden implementiert: Die Methode, in der die Funktion benötigt wird, entspricht dem Entwurfsmuster „Schblonenmethode“. In ihr wird die Hook-Methode aufgerufen. Soll die Funktion geändert werden, wird dem Entwurfsmuster entsprechend nur die Hook-Methode überschrieben.

Methodenaustausch zur Laufzeit Ist eine Verhaltensänderung während der Laufzeit erforderlich, so erhält die Schablonen- Klasse ein Feld vom Typ einer abstakten Hook-Klasse mit einer neuen abstrakten Hook-Methode, welche in den Unterklassen implementiert wird. Diese Methode wird von der ursprünglichen Hook-Methode aufgerufen. Da neue Unterklassen der Hook-Klasse aber jederzeit nachgeladen und dem Feld zugewiesen werden können, ist somit auch ein Austausch der neuen Methode währen der Laufzeit möglich.

Literatur Tom Cargill: C++ Programming Style. Addison-Wesley, 1992 Wolfgang Pree: Framework Patterns. SIGS Publications, 1996 Gamma, Helm, Johnson, Vlissides: Entwurfsmuster. Addison-Wesley, 1996