Objektorientiertes Design

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

1. Vererbung Co.
2. Konsistenz
3. Überladen von Operatoren
4. 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-Beis
  piel 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

1. Vererbung Co.
2. Konsistenz
3. Überladen von Operatoren
4. 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

1. Vererbung Co.
2. Konsistenz
3. Überladen von Operatoren
4. 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 Hot-Spot Name
Erforderliche Flexibilität Änderung ohne Neustart (Ja/Nein) Änderung durch User (Ja/Nein)
Semantische Beschreibung Semantische Beschreibung
Funktion Beschreibung des Verhaltens in Beispielsituationen Daten Beispieldaten 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