23
Objektorientiertes Objektorientiertes Design Design Clemens Haindl

Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

Embed Size (px)

Citation preview

Page 1: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

Objektorientiertes DesignObjektorientiertes DesignClemens Haindl

Page 2: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

InhaltInhalt

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

Page 3: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. 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.

Page 4: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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++)

Page 5: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 6: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 7: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

InhaltInhalt

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

Page 8: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. 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.

Page 9: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 10: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 11: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 12: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

InhaltInhalt

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

Page 13: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. 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!

Page 14: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

Mögliche ProblemquellenMögliche Problemquellen

Diverse KonvertierungenMehrdeutige ÜberladungenDefault-ArgumenteKonstruktorenVererbungBeispiel: FileArray

Page 15: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

InhaltInhalt

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

Page 16: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. 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

Page 17: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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)

Page 18: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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

Page 19: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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

Page 20: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 21: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 22: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

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.

Page 23: Objektorientiertes Design Clemens Haindl. Inhalt 1. Vererbung & Co. 2. Konsistenz 3. Überladen von Operatoren 4. Frameworks & Entwurfsmuster

LiteraturLiteratur

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

Wolfgang Pree: Framework Patterns. SIGS Publications, 1996

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