Entwurfsmuster

1. Entwurfsmuster

2. Inhalt 4. Patterns und Frameworks • Einführung: was ist und wozu braucht man Patterns u. Frameworks ? • wie werden Patterns beschrieben ? • Beispiele für Designpatterns • Singleton • Proxy • State • Beobachter/Observer • Adapter • Kompositum • Dekorierer • Abstrakte Fabrik

3. Einführung 4. Patterns und Frameworks was ist und wozu braucht man Patterns und Frameworks? • Software-Entwicklung ist mühsam • wiederverwendbare Software zu schreiben, ist noch mühsamer • Hilfe bei dieser Mühe: Design-Patterns und Frameworks, die für häufig wiederkehrende Probleme bewährte Lösungsmuster anbieten

4. Einführung 4. Patterns und Frameworks Geschichte der Patterns • Christopher Alexander (1977): A Pattern Language wie können Standardlösungen immer wiederkehrender Innenarchitekturprobleme sprachlich formuliert werden? • Erich Gamma, R.Helm, R. Johnson, J. Vlissides (1995): GoF Design Patterns – Elements of reusable OO-Software legten einen bis heute massgebenden Katalog von 23 Patterns vor • heute: es gibt kaum OO-Entwicklungen ohne Patterns ! es gehört zum Grundvokabular eines jeden SW-Ingenieurs !

5. Einführung 4. Patterns und Frameworks zunächst einige wichtige Begriffe Software Design Die Aktivitäten, die aus den Anforderungen an ein Softwaresystem eine Softwarelösung entwerfen. Diese Lösung beschreibt die Systemstruktur als Systemarchitektur (siehe nächste Folie) und dient der Implementation des Systems als Blueprint. . • der Design enthält nicht die Implementation des Systems • der Design enthält die eigentliche Lösung eines Problems • der Design wird methodisch und mit Diagrammtechniken erarbeitet

6. Einführung 4. Patterns und Frameworks wichtige Begriffe Software-Architektur eine Beschreibung der Teilsysteme und Komponenten eines Softwaresystems und deren Beziehungen untereinander. Teilsysteme und Komponenten werden unter verschiedenen Blickwinkeln betrachtet, um verschiedene funktionale und nichtfunktionale Aspekte zu beschreiben. Eine Softwarearchitektur ist das Resultat des Software-Designs. • Komponenten sind gekapselte, mit Schnittstellen versehene Systemteile: Module, Bibliotheken, Klassen/Objekte • nichtfunktionale Aspekte: z.B. Erweiterbarkeit, Zuverlässigkeit, Kosten, Wartbarkeit, Portierbarkeit • Beziehungen: zB. statisch, dynamisch, abhängig, enthalten, abgeleitet

7. Einführung 4. Patterns und Frameworks wichtige Begriffe Framework Ein teilweise vorgefertigtes Softwaresystem das noch "instanziiert" werden muss durch Einfügen fehlender Teile. Dabei wird eine Architektur vordefiniert, in der wesentliche Komponenten vorgefertigt sind, und diejenigen Stellen werden genau definiert, in denen das Framework mit Implementationen für ein spezielles System noch instanziiert werden muss/kann. . • Frameworks sind die grösstmöglich vorgefertigten Systemrohbauten • Frameworks sind meist typisch für ganze Anwendungsbereiche, zB.: • für interaktive Systeme mit GUIs – MFC (C++), JFC (JAVA) • für verteilte OO-Systeme – CORBA, DCOM

8. Einführung 4. Patterns und Frameworks Pattern Einordnung • Idiom Programmiermuster – wie in einer bestimmten Programmiersprache kleine Programmierprobleme gelöst werden. Beispiel in C/C++: wie man ein Feld durchläuft • Spezifischer Design ein spezifischer, persönlicher Design für ein bestimmtes Problem. Kann schlau sein, aber versucht nicht, allgemein anwendbar zu sein • Standard Design ein Design für ein bestimmtes Problem, der Allgemeinheit erlangt hat durch Wiederverwendung. Z.B. eine unternehmensweite Lösung für das Y2000-Problem • Design Pattern eine Lösung für eine ganze Klasse von ähnlichen Problemen. Meistens erst sichtbar nach längerer Anwendung von Standard-Designs.

9. Einführung 4. Patterns und Frameworks wie wird man ein guter Schachspieler? • lerne Regeln Figurenamen und –zugmöglichkeiten, Schachbrettgeometrie etc. • lerne Prinzipien relativer Figurenwert, strategischer Wert des Brettzentrums, Angriffsvermögen etc. • schliesslich und vor allem: lerne von Spielen der Meister Spielzüge und deren Anwendungssituationen: Muster (Patterns) es gibt hunderte von solchen Spielzügen/Strategien

10. Einführung 4. Patterns und Frameworks wie wird man ein guter Software-Designer? • lerne Regeln Algorithmen, Datenstrukturen, Programmiersprachen • lerne Prinzipien modulares Programmieren, objektorientiertes Programmieren • schliesslich und vor allem: lerne von SW-Designs der "Meister" Muster (Patterns) von allgemeinen Lösungen immer wiederkehrender Designprobleme

11. Objekt in globaler Variablen keine Garantie für Einmaligkeit besser: lasse die Klasse selber ihren Konstruktor überwachen Einführung 4. Patterns und Frameworks Pattern Beispiel: Singleton • Absicht stellt sicher, daß von einer Klasse höchstens ein Objekt erzeugt wird, und stellt einen globalen Zugriff auf das Objekt bereit • Motivation in manchen Anwendungen dürfen einige Klassen nur eine Objektinstanz besitzen – z.B. ein Printer-Spooler Objekt, ein Firma Objekt, ein Windows Manager Objekt, ein Roboter Objekt mit Konfigurationsdaten zur Robotersteuerung, ein DB-Broker.

12. Einführung 4. Patterns und Frameworks Beispiel: Singleton • Idee • verberge alle Konstruktoren nach aussen: mache sie private • biete eine neue Methode "instance" nach aussen an, die eine Referenz auf (das einzige) Objekt zurückgibt • diese Methode muss eine Klassenoperation sein (static)! warum?

13. das Klassenattribut s hält eine Referenz auf das einzige Objekt der Klasse Singleton mindestens einen Konstruktor definieren als private: kein (öffentlicher) Default- Konstruktor mehr verfügbar einzige öffentliche Zugriffs- methode auf ein Singleton- Objekt: ist Klassenmethode Benutzung: s referenziert das einzige Singleton-Objekt Singleton s = Singleton.Instance(); Einführung 4. Patterns und Frameworks Beispiel: Singleton class Singleton { private static Singleton s = new Singleton(); private Singleton() { . . } public static Singleton Instance() { return s; } . . . //Attribute und Methoden }

14. Einführung 4. Patterns und Frameworks Beispiel: Singleton (JAVA) public class SingletonPattern { public static void main(String[] args) { Singleton s = Singleton.Instance(); System.out.println(s.getValue()); Singleton s2 = Singleton.Instance(); s2.setValue(9); System.out.println(s.getValue()); } } class Singleton { private static Singleton s = new Singleton(99); private int i; private Singleton(int x) { i = x; } public static Singleton Instance() { return s; } public int getValue() { return i; } public void setValue(int x) { i = x; } } Ausgabe: 99 9

15. Einführung 4. Patterns und Frameworks es gibt drei Pattern Typen • Erzeugungsmuster (creational pattern) beschreiben Strukturen, die den Prozeß der Objekterzeugung enthalten. Das Anwendungsprogrammwird von der konkreten Realisation der Objekterzeugung entkoppelt. Es arbeitet auf einer höheren Abstraktionsebene und delegiert die Erzeugung der Objekte an die Erzeugungsstrukturen • Strukturmuster(structural pattern) zeigen auf, auf welche Art und Weise Klassen bzw. Objekte zu größeren Strukturen zusammengefaßt werden können. Nahezu alle der vonStrukturmustern beschriebenen Strukturen entstehen zur Laufzeit, beruhen also auf der Technik der dynamischen Objektkomposition

16. Einführung 4. Patterns und Frameworks es gibt drei Pattern Typen • Verhaltensmuster (behavioral patterns) beschreiben Strukturen, die am Kontrollfluß innerhalb der Anwendung beteiligt sind. Sie konzentrieren sich also auf Algorithmen und dieDelegation von Zuständigkeiten.

17. Einführung 4. Patterns und Frameworks

18. Einführung 4. Patterns und Frameworks Vorteile von Entwurfsmustern • Entwickler lernen schnell besseres Design • Entwickler werden produktiver • Qualität der Software wird besser • Kommunikation zwischen Entwicklern wird besser • Kommunikation bei der Wartung wird besser

19. Patternbeschreibung 4. Patterns und Frameworks • Nameden wir als Kürzel für das Muster benutzen können, wenn wir uns darüber unterhalten. • Absicht kurze (1 – 2 Sätze) Beschreibung des Ziels des Patterns • Problembeschreibt die typische Situation, die eine neue Lösung erfordert. Oft wird hier ein ganz konkretes Problem beschrieben,anhand dessen das einzuführende Muster ausprobiert werden kann. • Lösungsideeskizziert, wie das Muster aussehen könnte, mit dem das im vorigen Abschnitt beschriebene Problem gelöst werden könnte. • Strukturwird in einem UML Diagramm angegeben, das die statische Struktur der beteiligten Klassen verdeutlicht. • Die BeteiligtenHier werden die beteiligten Klassen noch einmal in Worten aufgezählt und ihre Rollen ausführlicher beschrieben.

20. Patternbeschreibung 4. Patterns und Frameworks • Zusammenspiel erklärt die Kooperation zwischen den beteiligten Klassen. DieserAbschnitt enthält oft auch ein (UML) Diagramm, in dem der Austausch von Nachrichten zwischen Objekten verdeutlicht wird. • Anwendbarkeit beschreibt Situationen, in denen das Muster sinnvoll eingesetzt werden kann, bzw. die Bedingungen, die gelten müssen, damit es eingesetzt werden kann. • Folgenbeschreibt die Vor- und Nachteile, die dieses Muster mit sich bringt. • Implementation diskutiert Aspekte, die bei Implementation des Musters zu bedenkensind • Codebeispielegibt konkrete Implementationen des Musters an anhand eines typischen Problems, in den wichtigsten OO-Sprachen (JAVA, C++) • Bekannte Anwendungen (bekannt!) • Verwandte Mustergeht auf Beziehungen zwischen diversen Mustern ein; es ist selten so, daß eine Problemklasse nurdurch ein einziges Muster allein entschärft wird.

21. Proxy 4. Patterns und Frameworks • Name Proxy • Absicht stelle ein Stellvertreter/Platzhalter für ein Objekt zur Verfügung, um über dieses Platzhalter-Objekt Zugriff auf das ursprüngliche Objekt zu garantieren • Problem manchmal ist die Erzeugung und Initialisierung eines Objektes aufwendig – grosse Datenmenge (z.B. Bilddaten), oder "entlegener" Ort wo das Objekt gespeichert ist (Netz, verteilte DB), oder grosse Anzahl von Objekten bei Initialisierung einer komplexen Anwendung • Lösungsidee verschiebe die Objektinitialisierung bis zum eigentlichen Gebrauch seitens des Verwenders (Klient), und stelle ihm solange nur ein Stellvertreterobjekt zur Verfügung (Schnittstelle mit den Operationen des eigentlichen Objekts). Der Klient soll den Proxy so sehen als ob er das richtige Objekt wäre.

22. Proxy 4. Patterns und Frameworks Struktur Klassendiagramm Subjekt {abstract} operation() . . . () Klient EchtesSubjekt operation() . . . () Proxy operation() . . . () vertritt operation() { vertritt.operation(); } Objektdiagramm operation() einKlient: operation() einProxy: einEchtesSubjekt:

23. Proxy 4. Patterns und Frameworks • Rollen Klient: greift auf ein Subjekt über ein Proxy zu, so als ob es ein EchtesSubjekt wäre. Er ist aber nur mit dem Proxy direkt verbunden (Referenz, Zeiger) Subjekt: stellt die gemeinsame Schnittstelle dar, sodass Proxy überall dort verwendet werden kann, wo eine EchtesSubjekt gebraucht wird. Hält meistens nur die Operationen (alle Attribute von EchtesSubjekt geschützt). Insbesondere stellt Subjekt sicher, dass Proxy und EchtesSubjekt gleich aussehen Proxy: ist der Ansprechpartner für Nachrichten eines Klients. Hält eine Referenz/Zeiger auf das EchteSubjekt, und ist verantwortlich für die Erzeugung (und evtl. Zerstörung) von EchtesSubjekt. EchtesSubjekt: enthält die Daten und den Programmcode

24. Proxy 4. Patterns und Frameworks Rollen (Fortsetzung) es gibt mehrere Typen von Proxy: • Remote-Proxy EchtesSubjekt (Objekte) befindet sich in einem anderen Adressraum (anderer Prozess, oder woanders im Netzwerk). Ein Remote-Proxy kodiert und schickt einen Request (IPC) an EchtesSubjekt • Virtuelles Proxy erzeugt ein umfangreiches Objekt im gleichen Adressraum "auf Anfrage" • Schutz-Proxy kontrolliert den (geschützten) Zugriff auf EchtesSubjekt, z.B. über Zugriffsrechte

25. Proxy 4. Patterns und Frameworks Folgen • ein Remote-Proxy kann einem Klient verbergen, dass das ange-sprochene Objekt (EchtesSubjekt) in anderem Adressraum liegt • ein Virtuelles Proxy kann optimieren: • verzögerte Objektinitialisierung (vielleicht nie) • Lastausgleich bei initialisierungsintensiven Anwendungen • ein virtuelles Proxy kann selber einfache Daten halten

26. Proxy 4. Patterns und Frameworks

27. Proxy 4. Patterns und Frameworks Beispiel in Java: virtueller Proxy interface Subjekt { intgetA(); floatgetB(); } class Proxy implements Subjekt { private EchtesSubjektvertritt; // delegiere Methodenaufrufean EchtesS: public intgetA() { return getEchtesSubjekt().getA(); } public floatgetB() { return getEchtesSubjekt().getB(); } protected EchtesSubjekt getEchtesSubjekt() { if ( vertritt == null ) vertritt = new EchtesSubjekt(); return vertritt; } } class EchtesSubjekt implements Subjekt { protected int a; protected int b; public int getA() { System.out.println("EchtesSub.getA()"); return a; } public float getB() { System.out.println(" EchtesSub.getB()"); return b; } public EchtesSubjekt() {a=1; b=1;} } public class Klient { public static void main(String args[]) { Proxy p = new Proxy(); System.out.println(" a: " + p.getA() ); System.out.println(" b: " + p.getB() ); } } lazy initialization

28. Zustand/State 4. Patterns und Frameworks • Name Zustand/State • Absicht lass ein Objekt sein Verhalten ändern (Ausführung einer Operation) wenn sein interner Zustand sich ändert • Problem ein Objekt hat interne Zustände (Attributwerte), die einige seiner Operationen beeinflussen. z.B. Datei öffnen: Datei dateiname : String oeffnen() schliessen() weitereOp() Datei dateiname : String offen : boolean oeffnen() schliessen() weitereOp() Spezialisierung Problem: ein Dateiobjekt müsste seine Klasse wechseln können OffeneDatei oeffnen() schliessen() GeschlosseneDatei oeffnen() schliessen()

29. Zustand/State 4. Patterns und Frameworks • Lösungsidee lagere den zustandsabhängigen Teil aus der Klasse aus (eigene Klasse), implementiere in der Klasse nur den zustandsunabhängigen Teil, und delegiere zustandsabhängige Operationen an die ausgelagerte Klasse • Struktur 1 KlasseMitZustand Zustand {abstract} state opAbhängig() opUnabhängig() opAbhängig() operation() { state.opAbhängig(); } ZustandA ZustandB . . . opAbhängig() opAbhängig() Zustandsänderung: - wie wird er geändert ? - wer bzw. wo wird ein Zustand geändert ?

30. Zustand/State 4. Patterns und Frameworks Rollen • KlasseMitZustand die eigentliche Klasse, die nur den zustandsunabhängigen Teil enthält (evtl. mit Operationen die den Zustand verändern). Sie hält eine Referenz auf den aktuellen Zustand, über die zustandsabhängige Operationen delegiert werden. • Zustand abstrakte Schnittstelle (Polymorphismus) für die delegierten, zustandsabhängigen Operationen • konkreter Zustand (ZustandA, ZustandB) implementieren die zustandsabhängigen Operationen Zustandsänderungen: ersetze aktuell referenziertes Zustandsobjekt durch ein neues

31. Zustand/State 4. Patterns und Frameworks Anwendbarkeit: • wenn ein Objekt Operationen hat, deren Logik von einem Zustand des Objektes selber abhängt der sich zur Laufzeit ändern kann • das Objekt wenig Zustände hat und die Zustandsübergänge selber einen einfache Zustandsübergangsgraphen besitzen • falls 2 nicht erfüllt ist, empfiehlt sich eine Realisierung mit einem endlichen Zustandsautomat

32. Zustand/State 4. Patterns und Frameworks wenn man komplexe Zustandsübergänge hat, benutzt man vorzugsweise einen endlichen Zustandsautomaten: Zustand Ereignis z_1 z_2 . . . z_i . . . Zustand z_i e_1 e_2 . . . e_k . . . Ereignis e_k / Aktion a_m Zustand z_j im Zustand z_i führt das Ereignis e_k zum Folgezustand z_j und löst Akton a_m aus Darstellung in einer Tabelle von Paaren: (folgezustand,aktion)

33. Zustand/State 4. Patterns und Frameworks ComplexClass StateTransitionTable ... actState : State act : Action ... hasSTT stTable //state table create(ComplexClass cp) //loads table save() addState( State st ) addEvent( Event ev ) addTransition(State st1, State st2, Event ev, Action act) removeState(...) ... State transit( State st, Event ev, Action &act) 1..* 1 event1(..) { //operation op1 implements event 1 actState = hasSTT.transit(actState, E1, act ); switch (act) { case A1: action1(..); //execute action break; case A2: action2(..); . . . } event2(..) ... action1(..) //action A1 action2(..) //action A2 . . .

34. Zustand/State 4. Patterns und Frameworks Konsequenzen • es strukturiert das Objektverhalten nach Zuständen: • jede Zustandsklasse enthält die Zustandsbesonderheiten • leichter les- und vor allem wartbar • unterstützt Zustandsklassifizierung: Zustände sind manchmal klassifizierbar durch Super-/Subklassenbeziehungen • Zustände werden explizit gemacht

35. Beobachter/Observer 4. Patterns und Frameworks • Name: Beobachter (Observer) • AbsichtObjekte können Daten bei einem Informationsanbieterabonnieren. Bei jeder Änderung der abonnierten Daten werden dieAbonnenten automatisch über die Änderung informiert,die sich dann die geänderten Daten holen. • Problem voneinander abhängige Objekte sollen nicht zu stark aneinander gekoppelt werden, was Wiederverwendbarkeit einschränken würde. • Lösungsidee Trennung von Informationsbereitsteller und einer Menge vonInformationsverarbeitern bzw. Darstellern der Information. Die Bereitsteller müssen die Verarbeiter nicht direkt kennen: statt direkter Kommunikation über Aufrufe benutze eine indirekte überBenachrichtigungen.

36. Beobachter/Observer 4. Patterns und Frameworks Struktur beobachtetVon ► * Beobachter Subjekt {abstract} {abstract} 1..* ◄ beobachtet - beobachtet : Subjekt - beobachtetVon : ListOfBeobachter #benachrichtigen() +registrieren(beob:Beobachter) +löschen(beob:Beobachter) +aktualisieren(. . . ) für alle beo in beobachtetVon: beo.aktualisieren(. . . ); beobachtet.getMeineDaten(); . . . //aktualisiere zustand MeinSubjekt MeinBeobachter Client -meineDaten : Data - zustand . // bearbeite und . // aktualisiere . // meineDaten benachrichtigen(); +getMeineDaten(): Data +setMeineDaten(d:Data) . . . +aktualisieren(. . . ) setMeineDaten(x)

37. Beobachter/Observer 4. Patterns und Frameworks Teilnehmer • Subjekt kennt seine Beobachter (beliebig viele) als abstrakte Beobachter; bietet Schnittstelle zur (Ent)Registrierung von Beobachtern; hat Operation zur Benachrichtigung registrierter Beobachter • Beobachter bietet einen Typ (abstrakte Klasse/Interface) der benachrichtigt werden kann von Subjekten • MeinSubjekt wird unabhängig von Beobachtern programmiert: hält aber Daten von denen Beobachter-Objekte abhängig sind; sendet (fast automatisch) Benachrichtigungen an Beobachter-Objekte wenn Daten sich ändern • MeinBeobachter ist abhängig und hält eine Referenz zu einem MeinSubjekt-Objekt; enthält Daten die mit Daten des Subjekts konsistent sein müssen; implementiert die aktualisiere-Operation zur Benachrichtigung

38. Beobachter/Observer 4. Patterns und Frameworks Zusammenspiel • jedes Objekt der Klasse Subjekt führt eine Liste von Beobachtern,welche an Veränderungen im Zustand dieses Objekts interessiert sind.registrieren bzw. loeschen fügt Beobachter in die Liste ein bzw. entferntsie. • nach jeder Veränderung schickt das Subjekt sich selbstdie Nachricht benachrichtigen. Diese iteriert die Liste der Beobachterund schickt jedem Beobachter die Nachricht aktualisieren. Ggf. können Informationen (z. B. die Art des eingetretenen Ereignisses, oder dasbenachrichtigende Objekt selber) alsParameter mitgegeben werden. • jeder benachrichtigte Beobachter reagiert, indem er beim benach-richtigenden Sujekt mit getXXX- Nachrichten die ihninteressierenden Informationen abruft. • alternativ können der aktualisiere-Nachricht die veränderten Daten gleichmitgegeben werden, wodurch der Abruf durch getXXX entfällt. Dieses "Bring"-Prinzip ist effizient, koppelt aber Subjekt und Beobachterstärker als das mit getXXX realisierte "Hol"-Prinzip.

39. Beobachter/Observer 4. Patterns und Frameworks Zusammenspiel ms :MeinSubjekt mb :MeinBeobachter db :DeinBeobachter registrieren mb registrieren db setMeineDaten benachrichtigen aktualisieren getMeineDaten Data aktualisieren getMeineDaten Data

40. Beobachter/Observer 4. Patterns und Frameworks Anwendbarkeit • wenn eine Änderung in einem Objekt Änderungen in anderen verlangt, und das erstere weiss zur Programmierzeit oder zum Systemstart nicht, welche anderen von ihm abhängen • wenn man also dynamische Abhängigkeiten hat • wenn man Abhängigkeiten in reinen Client/Server-Beziehungen modellieren möchte zwecks leichterer Änderbarkeit weiss von Serverklasse Clientklasse weiss nichts von

41. Beobachter/Observer 4. Patterns und Frameworks Folgen • schwache, einseitige Kopplung zwischen unabhängiger und abhängigen Klassen: erstere kennt nur eine abstrakte Schnittstelle zur Benachrichtigung • sauberer Design: Aktualisierungslogik im abhängigen Teil, nicht im bestimmenden (nur benachrichtigen, nicht aktualisieren) • dadurch können die beiden Klassentypen zu unterschiedlichen Systemebenen gehören (nächste Folie) • unterstützt eine Art Broadcasting

42. Beobachter/Observer 4. Patterns und Frameworks bekannte Anwendungen von Präsentationsschicht unabhängige Anwendungslogik GUI-Komponenten repräsentieren Daten der Anwendungslogikschicht Präsentationsschicht GUI-Kom- ponente1 GUI-Kom- ponente2 GUI-Kom- ponente3 Klassen der Anwendungslogikschicht verarbeiten Daten, ohne sie am Bild- schirm zu präsentieren Klasse1 Klasse2 Anwendungslogikschicht Abhängigkeit

43. Beobachter/Observer 4. Patterns und Frameworks Implementation • wann soll die Registrierung (Löschen) geschehen? meistens im Konstruktor (Destruktor) eines Beobachters • mehrere Subjekte: wie erkennen, welches Subjekt benachrichtigt? Parameter des Subjektes (this) bei Benachrichtigung übergeben • muss immer gleich aktualisiert werden? nein, man kann eine lazy-computing Technik einsetzen

44. Beobachter/Observer 4. Patterns und Frameworks lazy computing: erst dann berechnen, wenn Daten gebraucht werden MeinBeobachter -meinAttribut: Typ //abhängiges Attr. -meinAttributStatus //valid/invalid void benachrichtige() { meinAttributStatus = invalid; } Client +benachrichtige() +getMeinAttribut(): Typ getMeinAttribut() Typ getMeinAttribut() { if (meinAttributStatus == invalid) { beobachtet.getMeineDaten(); . . . //Neuberechnung von meinAttribut meinAttributStatus = valid; } return meinAttribut; } Vorteil: weniger Berechnungen, falls Subjekt wesentlich öfter benachrichtigt als Beobachter befragt wird

45. Beobachter/Observer 4. Patterns und Frameworks interface Beobachter { public void aktualisieren(Subjekt subjekt); } class Subjekt{ Beobachter[] beobachtetVon = new Beobachter[MAXOBS]; int anzBeobachter = 0; public void registrieren( Beobachter beob ) { beobachtetVon[ anzBeobachter++] = beob; } public void löschen( Beobachterbeob ) { for (int i = 0; i < anzBeobachter; ++i ) { if (beobachtetVon[i] == beob) { --observerCnt; for (;i < anzBeobachter; ++i) beobachtetVon[ i ] = beobachtetVon[i + 1]; break; } } }

46. Adapter 4. Patterns und Frameworks • Name: Adapter • Absicht • erlaubt die Zusammenarbeit von Klassen die unterschiedliche Schnitt- • stellenhaben. Adapter wird als verbindendes Element zwischen die • beiden Klassen eingefügt. • Problem • Schnittstellenproblem: eine Klasse "Verwender"(Klient) soll eine andere • Klasse "Dienstanbieter" (Ziel) verwenden. DerVerwender kann jedoch • auf den Dienstanbieter nicht zugreifen, da der Verwender eine andere • Schnittstelle erwartet, als die, die vom Dienstanbieterangeboten wird. • Lösungsidee • Der Dienstanbieter wird in einen Adapter eingepackt. Der Adapter • bietet die Schnittstellean, die der Verwender benötigt. • Dazu gibt es zwei Varianten: • Objektadapter • Klassenadapter

47. Adapter 4. Patterns und Frameworks Struktur: Objektadapter adaptiert Ziel operation() AdaptierteKlasse spezifischeOperation() Klient Adapter operation() operation() . . . adaptiert.spezifischeOperation() . . . Adaption: • andere Operationensignatur – Operations- und Parameternamen, Parametertypen und -reihenfolge • andere Operationsfunktionen – ähnliche, aber nicht genau gleiche Semantik

48. TextAnzeige getUrsprung() getHoehe() getBreite() zeigMich() Adapter 4. Patterns und Frameworks Adapter Beispiel: ein Zeicheneditor mit fremder Komponente TextAnzeige GraphischesObjekt {abstract} begrenzungsRahmen() zeichne() 1 manipuliert * Zeicheneditor zeichne() begrenzungsrahmen() Linie begrenzungsRahmen() zeichne() Kreis begrenzungsRahmen() zeichne() TextAnzeige passt nicht zu GraphischesObjekt: Problem für den Zeicheneditor

49. einseitige Beziehung: TextAnzeige auch ohne Source verwendbar TextAnzeige getUrsprung() getHoehe() getBreite() zeigMich() Adapter 4. Patterns und Frameworks Adapter Beispiel: ein Zeicheneditor mit fremder Komponente TextAnzeige 1 text GraphischesObjekt {abstract} begrenzungsrahmen() zeichne() 1 manipuliert * Zeicheneditor zeichne() begrenzungsrahmen() Linie begrenzungsrahmen() zeichne() Kreis begrenzungsrahmen() zeichne() Text begrenzungsrahmen() zeichne() 1 zeichne() . . . text.zeigMich() . . . begrenzungsrahmen() text.getHoehe() text.getBreite() . . .

50. Adapter 4. Patterns und Frameworks Struktur: Klassenadapter Ziel operation() AdaptierteKlasse spezifischeOperation() Klient Adapter operation() operation() . . . spezifischeOperation() . . . benutzt Mehrfachvererbung