Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen...

Objektorientiertes DesignObjektorientiertes DesignClemens Haindl

InhaltInhalt

1. Vererbung & Co.2. Konsistenz3. Überladen von Operatoren4. Frameworks & Entwurfsmuster

AbstraktionAbstraktion

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.

VererbungVererbung

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: ListenAlternativen: Dynamische Bindung

(.NET) bzw. Templates (C++)

KopplungKopplung

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.

FolgerungenFolgerungen

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.

InhaltInhalt

1. Vererbung & Co.2. Konsistenz3. Überladen von Operatoren4. Frameworks & Entwurfsmuster

Konsistenz - KonstruktorenKonsistenz - 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 - NachvollziebarkeitKonsistenz - 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.

InvariantenInvarianten

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.

RedundanzRedundanz

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.

InhaltInhalt

1. Vererbung & Co.2. Konsistenz3. Überladen von Operatoren4. Frameworks & Entwurfsmuster

Allgemeine RegelnAllgemeine 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 ProblemquellenMögliche Problemquellen

Diverse KonvertierungenMehrdeutige ÜberladungenDefault-ArgumenteKonstruktorenVererbungBeispiel: FileArray

InhaltInhalt

1. Vererbung & Co.2. Konsistenz3. Überladen von Operatoren4. Frameworks & Entwurfsmuster

Anno 1996Anno 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 DesignHot-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-SpotsIdentifizierung 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 CardBeispiel: 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 - DatenImplementierung - 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 - FunktionImplementierung - 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 LaufzeitMethodenaustausch 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.

LiteraturLiteratur

Tom Cargill: C++ Programming Style. Addison-Wesley, 1992

Wolfgang Pree: Framework Patterns. SIGS Publications, 1996

Gamma, Helm, Johnson, Vlissides: Entwurfsmuster. Addison-Wesley, 1996