Objektorientiertes Design

Präsentation zum Thema: "Objektorientiertes Design"—  Präsentation transkript:

1 Objektorientiertes Design
Clemens Haindl

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

3 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.

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

5 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.

6 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.

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

8 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.

9 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.

10 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.

11 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.

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

13 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!

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

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

16 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

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

18 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

19 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

20 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.

21 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.

22 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.

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