Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Transkript

1 Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte 6.7 Anwendungsfälle und Benutzerschnittstelle 6.8 Anwendungsfälle und Interaktionsdiagramme 6.9 Anwendung von GRASP Entwurfsmustern 6.10 Entwurfsmuster der Gang of Four (GoF) 6.11 Entwurfsmuster zur Model-View Architektur 6.12 Lösungen mit Objekten und Entwurfsmustern 6.13 Spezielle Design-Probleme 6.15 Weitere GoF Pattern Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 490 Wir wollen weitere 4 Pattern als Kriterien zur Verbesserung des Designs kennenlernen: Polymorphism Pure Fabrication Indirection Don t Talk to Strangers Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 491

2 Polymorphismus Gib ähnliche Services in verschiedenen Klassen denselben Namen, aber variiere die Implementierung Die verschiedenen Klassen müssen i.a. in einer gemeinsamen Vererbungshierarchie sein (Ausnahme: Interfaces in Java) Zweck: Wenn miteinander zusammenhängende Alternativen oder Verhalten mit dem Datentyp (der Klasse) variiert, weise Zuständigkeiten für dieses Verhalten den Klassen zu, bei denen sich das Verhalten unterscheidet Verwende dazu polymorphe Operationen Korollar: Prüfe nicht den Typ eines Objektes und verwende dann bedingte Logik, um die Alternativen zu unterscheiden Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 492 Polymorphismus Problem Verwendet man in einem Programm Bedingungskonstrukte (if-thenelse, switch-case), um Fälle zu unterscheiden, so bedarf es für jeden neuen, zusätzlichen Fall einer Ergänzung dieses logischen Konstruktes Erweiterungen des Programms bedingen Änderungen an mehreren Stellen Vor dem Hintergrund von austauschbaren Softwarekomponenten kann man das Verhältnis zwischen zusammenarbeitenden Objekten als Client/Server-Beziehung ansehen Wie kann ich dann eine Server-Komponente austauschen, ohne den Klienten zu betreffen? Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 493

3 Polymorphismus Unser Beispiel: Nehmen wir an, wir haben verschiedene Zahlungsweisen vorgesehen: Barzahlung Zahlung Kreditkarte betrag Scheck autorisiere() {abstract} Wo sollte die autorisiere Methode implementiert werden? Barzahlung Kreditkartenzahlung Scheckzahlung autorisiere() autorisiere() autorisiere() Die Implementierung jeder autorisiere Methode wird verschieden sein Mittels Polymorphismus autorisiert sich jede Zahlungsart selbst Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 494 Polymorphismus Diskussion: Wie beim Expert Pattern gilt auch hier derselbe Geist : Tue es selbst Wie Expert als das wichtigste taktische Pattern in der Objektorientierung ist, kann Polymorphismus als das wichtigste strategische Pattern angesehen werden Polymorphismus muss langfristiger für eine Architektur geplant werden als die Umsetzung des Expert Patterns Ein Design, das Zuständigkeiten auf der Basis des Polymorphismus Pattern zuweist, kann leicht erweitert werden, um neue Variationen zu unterstützen Leicht könnte man eine Zahlung per Lastschrift hinzufügen. Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 495

4 Pure Fabrication Pure Erfindung (???) Zweck: Weise eine Menge stark zusammenhängender Zuständigkeiten einer künstliche Klasse zu, die nichts Reales in der Anwendungsdomäne repräsentiert Etwas, das nur dazu dient, hohen Zusammenhalt, schwache Kopplung und gute Wiederverwendbarkeit zu unterstützen Erfindung der Imagination. Design ist üblicherweise sehr sauber daher pur Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 496 Pure Fabrication Unser Beispiel: Angenommen wir benötigen Unterstützung, um eine Verkaufs-Instanz in eine relationale Datenbank zu schreiben Nach dem Expert Pattern ist das Sache von Verkauf selbst Man beachte aber die folgenden Einwände: Um das Schreiben in die Datenbank zu realisieren, bedarf es einer Anzahl von datenbankspezifischen Operationen, die nichts mit dem eigentlichen Verkauf zu tun haben Dadurch erhielte die Klasse Verkauf schlechten Zusammenhalt. Die Verkaufs-Klasse wäre zusätzlich an die Schnittstelle zu der relationalen Datenbank (zugekaufte Software) gekoppelt Keine Kopplung zu einer anderen Domänen-Klasse sondern zu einer Schnittstelle zu einer Datenbank Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 497

5 Pure Fabrication... Man beachte aber die folgenden Einwände (fortgesetzt): Objekte in einer relationalen Datenbank zu speichern, ist eine häufig benötigte Zuständigkeit Diese sollte nicht jeder Klasse der Anwendungsdomäne gegeben werden, da dadurch wahrscheinlich sehr viel Code dupliziert würde Wiederverwendbarkeit wäre gering Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 498 Pure Fabrication Vernünftige Lösung: Zusätzliche Klasse, deren einzige Zuständigkeit es ist, irgendwelche Objekte auf irgendeinem persistenten Medium zu speichern Pure Fabrication Pattern PersistentStorageBroker save() Vorteile: Verkauf behält den sauberen Entwurf. Die Klasse PersistenStorageBroker ist relativ gut zusammenhängend. Einzige Verantwortlichkeit: Speichern von Objekten Die Klasse PersistenStorageBroker ist eine sehr generische und wiederverwendbare Klasse Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 499

6 Pure Fabrication Pure Fabrication Klassen orientieren sich an zusammenhängenden Funktionalitäten und sind daher eher funktions-zentrierte Klassen Viele existierenden Design Patterns sind Pure Fabrication Klassen: Adapter, Observer, Visitor, usw. Probleme: Der Geist der Objektorientierung kann durch diese funktionsorientierte Argumentation verletzt werden Wird Pure Fabrication missbraucht, dann führt es zu funktions- oder prozessorientiertem Design, das lediglich mit Hilfe einer objektorientierten Sprache implementiert wird Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 500 Indirection Pattern Zweck: Weise einem Objekt eine Zuständigkeit zu, so dass es zwischen anderen Komponenten oder Klassen vermittelt, damit diese nicht direkt gekoppelt sind Dadurch wird eine Indirection zwischen die anderen Komponenten eingefügt Beispiel: PersistentStorageBroker Das Pure Fabrication Beispiel ist auch ein Beispiel für Indirection: Die Klasse PersistentStorageBroker ist auch ein Mittler zwischen Verkauf und dem Datenbanksystem Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 501

7 Indirection Pattern Beispiel: Modem Annahme: Unser Kassenterminal muss ein Modem verwenden, um Kreditkartenzahlungen zu autorisieren Das Betriebssystem stellt eine low-level API dafür zur Verfügung Die Klasse KreditAutorisierungsService ist dafür zuständig, mit dem Modem zu kommunizieren Würde KreditAutorisierungsService direkt das low-level API aufrufen, wäre diese Klasse eng an diese sehr spezielle API gekoppelt Wollte man diese Klasse auf ein anderes Betriebssystem portieren, würde sie massive Modifikationen benötigen Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 502 Indirection Pattern Lösung Stattdessen fügen wir dazwischen eine Klasse Modem ein, die eine higher-level Schnittstelle für KreditAutorisierungsService bietet und diese Anforderungen auf die low-level API übersetzt Eine solche Klasse wird auch als Device Proxy bezeichnet Indirection Pattern dial() send() receive() Modem Modem::dial(nummer) { ::OS_OpenPort(1); ::OS_Dial(nummer); } autorisiere(betrag) :KreditAutorisierungs- Service 1: dial(nummer) :Modem Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 503

8 Zweck: Ein Klient habe eine Assoziation zu einem (direkten) Objekt Dieses wiederum habe eine Assoziation zu einem anderen (für den Klienten indirekten) Objekt Dann sollte das direkte Objekt die Zuständigkeit erhalten, mit dem indirekten Objekt zu kommunizieren (und nicht der Klient), so dass der Klient nichts über das indirekte Objekt wissen muss Dieses Pattern definiert Randbedingungen, zu welchen anderen Objekten Messages geschickt oder nicht geschickt werden sollten: Zu dem this Objekt (oder self) Einem Objekt, das Parameter einer Methode ist Einem Attribut von this Einem Element einer Collection, welche Attribut von this ist Einem Objekt, das innerhalb einer Methode erzeugt wurde Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 504 Dahinter steckt, dass vermieden werden soll, dass ein Klient an indirekte Objekte und an die interne Struktur direkter Objekte gekoppelt wird Direkte Objekte sind Vertraute des Klienten, indirekte Objekte sind Fremde Um dieses Pattern zu realisieren, müssen direkte Objekte ggf. neue Operationen implementieren, so dass der Klient nicht direkt mit dem indirekten Objekt reden muss Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 505

9 Unser Beispiel: Kasse hat ein Attribut, welches Verkauf referenziert. Verkauf hat ein Attribut, das Zahlung referenziert Teil-Klassendiagramm: Kasse Verkauf Zahlung gibzahlbetrag(): Float schliesseverkauf() bearbeiteware() machezahlung() hat datum: Datum zeit: Zeit istabgeschlossen: Boolean schliesseab() erzeugeverkpos() fuegezahlunghinzu() zahlung(): Zahlung gesamtsumme(): Float ist gezahlt durch gegebenerbetrag gibgegebenenbetrag(): Float Kasse besitzt Methode gibzahlbetrag(), welche den gegebenen Betrag liefert Verkauf besitzt Methode zahlung(), welche Referenz auf Zahlung liefert Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 506 (Leichter) Verstoß: float gibzahlbetrag() { Zahlung z = m_verkauf.zahlung(); // Verletzt das "Don't talk to Strangers" Pattern return z.gibgegebenenbetrag(); } b := gibzahlbetrag(): Float :Kasse 1: z := zahlung(): Zahlung :Verkauf 1.1: b := gibgegebenenbetrag() z:zahlung Verletzt "Don't Talk to Strangers" z ist ein "Fremder" für Kasse Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 507

10 Bessere Lösung Füge Klasse Verkauf weitere Zuständigkeit hinzu, d.h. Verkauf benötigt eine weitere Methode Damit ist die Forderung des Patterns erfüllt: float gibzahlbetrag() { return m_verkauf.gibgegebenenbetrag(); } Verkauf datum: Datum zeit: Zeit istabgeschlossen: Boolean schliesseab() erzeugeverkpos() fuegezahlunghinzu() zahlung(): Zahlung gibgegebenbetrag(): Float gesamtsumme(): Float b := gibzahlbetrag(): Float :Kasse 1: b := gibgegebenenbetrag :Verkauf 1.1: b := gibgegebenenbetrag() Unterstützt das "Don't Talk to Strangers" Pattern z:zahlung Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 508 Vorteile Das Pattern Don t Talk to Strangers verhindert, dass vorübergehende Assoziationen und somit Sichtbarkeiten zu Objekten erzeugt werden, die eigentlichen direkten Nachbarn schon bekannt sind, aber nicht dem Klienten Einhalten der Forderungen des Patterns verhindert überflüssige zusätzliche Kopplungen Details über den Zusammenhang zwischen Verkauf und Zahlung sind für Kasse gekapselt Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 509

11 Ausnahmen: Für jede Regel gibt es Ausnahmen: Falls es in einer Anwendungsarchitektur bestimmte Broker oder Mediator Objekte gibt, die verschiedene Objekte miteinander verknüpfen und deren Aufgabe es ist, z.b. aufgrund eines Schlüsselwertes die Referenz eines Objektes zurückzugeben, dann ist es akzeptabel, Sichtbarkeit über den Broker zu erlangen und auch auszunutzen. Prof. Dr. Björn Dreher Softwaretechnik (Medieninformatik) 510