Entwurfsmuster i Tec 1 Inhalt 4 Patterns und

Entwurfsmuster i. Tec 1

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

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

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

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. . q der Design enthält nicht die Implementation des Systems q der Design enthält die eigentliche Lösung eines Problems q der Design wird methodisch und mit Diagrammtechniken erarbeitet i. Tec 5

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. q Komponenten sind gekapselte, mit Schnittstellen versehene Systemteile: Module, Bibliotheken, Klassen/Objekte q nichtfunktionale Aspekte: z. B. Erweiterbarkeit, Zuverlässigkeit, Kosten, Wartbarkeit, Portierbarkeit q Beziehungen: z. B. statisch, dynamisch, abhängig, enthalten, abgeleitet i. Tec 6

Einführung 4. Patterns und Frameworks wichtige Begriffe Framework Ein teilweise vorgefertigtes Softwaresystem das "instanziiert" werden muss durch Einfügen fehlender Teile. noch 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. . q Frameworks sind die grösstmöglich vorgefertigten Systemrohbauten q Frameworks sind meist typisch für ganze Anwendungsbereiche, z. B. : – für interaktive Systeme mit GUIs – MFC (C++), JFC (JAVA) – für verteilte OO-Systeme – CORBA, DCOM i. Tec 7

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

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

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

Einführung 4. Patterns und Frameworks Pattern Beispiel: Singleton q Absicht stellt sicher, daß von einer Klasse höchstens ein Objekt erzeugt wird, und stellt einen globalen Zugriff auf das Objekt bereit q 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. Objekt in globaler Variablen keine Garantie für Einmaligkeit besser: lasse die Klasse selber ihren Konstruktor überwachen i. Tec 11

Einführung 4. Patterns und Frameworks Beispiel: Singleton q 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? i. Tec 12

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

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

Einführung 4. Patterns und Frameworks es gibt drei Pattern Typen 1. Erzeugungsmuster (creational pattern) beschreiben Strukturen, die den Prozeß der Objekterzeugung enthalten. Das Anwendungsprogramm wird von der konkreten Realisation der Objekterzeugung entkoppelt. Es arbeitet auf einer höheren Abstraktionsebene und delegiert die Erzeugung der Objekte an die Erzeugungsstrukturen 2. 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 von. Strukturmustern beschriebenen Strukturen entstehen zur Laufzeit, beruhen also auf der Technik der dynamischen Objektkomposition i. Tec 15

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

Einführung i. Tec 4. Patterns und Frameworks 17

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

Patternbeschreibung 4. Patterns und Frameworks q Name den wir als Kürzel für das Muster benutzen können, wenn wir uns darüber unterhalten. q Absicht kurze (1 – 2 Sätze) Beschreibung des Ziels des Patterns q Problem beschreibt 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. q Lösungsidee skizziert, wie das Muster aussehen könnte, mit dem das im vorigen Abschnitt beschriebene Problem gelöst werden könnte. q Struktur wird in einem UML Diagramm angegeben, das die statische Struktur der beteiligten Klassen verdeutlicht. q Die Beteiligten Hier werden die beteiligten Klassen noch einmal in Worten aufgezählt 19 i. Tec und ihre Rollen ausführlicher beschrieben.

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

Proxy q Name 4. Patterns und Frameworks Proxy q 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 q 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 q 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. i. Tec 21

Proxy 4. Patterns und Frameworks Struktur Klassendiagramm Klient Subjekt {abstract} operation(). . . () Echtes. Subjekt operation(). . . () vertritt Proxy operation(). . . () Objektdiagramm ein. Klient: operation() i. Tec ein. Proxy: operation() { vertritt. operation(); } operation() ein. Echtes. Subjekt: 22

Proxy 4. Patterns und Frameworks q Rollen Klient: greift auf ein Subjekt über ein Proxy zu, so als ob es ein Echtes. Subjekt 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 Echtes. Subjekt gebraucht wird. Hält meistens nur die Operationen (alle Attribute von Echtes. Subjekt geschützt). Insbesondere stellt Subjekt sicher, dass Proxy und Echtes. Subjekt gleich aussehen Proxy: ist der Ansprechpartner für Nachrichten eines Klients. Hält eine Referenz/Zeiger auf das Echte. Subjekt, und ist verantwortlich für die Erzeugung (und evtl. Zerstörung) von Echtes. Subjekt. i. Tec Echtes. Subjekt: enthält die Daten und den Programmcode 23

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

Proxy 4. Patterns und Frameworks Folgen q ein Remote-Proxy kann einem Klient verbergen, dass das angesprochene Objekt (Echtes. Subjekt) in anderem Adressraum liegt q ein Virtuelles Proxy kann optimieren: – verzögerte Objektinitialisierung (vielleicht nie) – Lastausgleich bei initialisierungsintensiven Anwendungen q ein virtuelles Proxy kann selber einfache Daten halten i. Tec 25

Proxy i. Tec 4. Patterns und Frameworks 26

Proxy 4. Patterns und Frameworks Beispiel in Java: virtueller Proxy interface Subjekt { int get. A(); float get. B(); } class Proxy implements Subjekt { private Echtes. Subjekt vertritt; // delegiere Methodenaufrufe an Echtes. S: public int get. A() { return get. Echtes. Subjekt(). get. A(); } public float get. B() { return get. Echtes. Subjekt(). get. B(); } } protected Echtes. Subjekt get. Echtes. Subjekt() { if ( vertritt == null ) vertritt = new Echtes. Subjekt(); return vertritt; } lazy initialization i. Tec class Echtes. Subjekt implements Subjekt { protected int a; protected int b; public int get. A() { System. out. println("Echtes. Sub. get. A()"); return a; } public float get. B() { System. out. println(" Echtes. Sub. get. B()"); return b; } public Echtes. Subjekt() {a=1; b=1; } } public class Klient { public static void main(String args[]) { Proxy p = new Proxy(); System. out. println(" a: " + p. get. A() ); System. out. println(" b: " + p. get. B() ); } } 27

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

Zustand/State 4. Patterns und Frameworks q 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 q Struktur operation() { state. op. Abhängig(); } Zustandsänderung: i. Tec Klasse. Mit. Zustand 1 state op. Abhängig() op. Unabhängig() Zustand {abstract} op. Abhängig() Zustand. A Zustand. B op. Abhängig() - wie wird er geändert ? - wer bzw. wo wird ein Zustand geändert ? 29 . . .

Zustand/State 4. Patterns und Frameworks Rollen q Klasse. Mit. Zustand 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. q Zustand abstrakte Schnittstelle (Polymorphismus) für die delegierten, zustandsabhängigen Operationen q konkreter Zustand (Zustand. A, Zustand. B) implementieren die zustandsabhängigen Operationen Zustandsänderungen: ersetze aktuell referenziertes Zustandsobjekt durch ein neues i. Tec 30

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

Zustand/State 4. Patterns und Frameworks Compservice: Statechart i. Tec 32

Zustand/State 4. Patterns und Frameworks wenn man komplexe Zustandsübergänge hat, benutzt man vorzugsweise einen endlichen Zustandsautomaten: Zu Er stan z z. . . zi. . . 1 2 e d i gn Zustand is zi e 1 Ereignis ek (folge/ e 2 zustand, Aktion am aktion). . . Zustand zj im Zustand zi führt das Ereignis ek zum Folgezustand zj und löst Akton am aus i. Tec ek. . . Darstellung in einer Tabelle von Paaren: (Folgezustand, Aktion) ( zj , am ) 33

Zustand/State 4. Patterns und Frameworks Complex. Class. . . act. State : State act : Action. . . event 1(. . ) { State. Transition. Table has. STT 1. . * //operation op 1 implements event 1 act. State = has. STT. transit(act. State, E 1, act ); switch (act) { case A 1: action 1(. . ); //execute action break; case A 2: action 2(. . ); . . . } event 2(. . ). . . action 1(. . ) //action A 1 action 2(. . ) //action A 2. . . i. Tec st. Table //state table 1 create(Complex. Class cp) //loads table save() add. State( State st ) add. Event( Event ev ) add. Transition(State st 1, State st 2, Event ev, Action act) remove. State(. . . ). . . State transit( State st, Event ev, Action &act) 34

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

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

Beobachter/Observer 4. Patterns und Frameworks Struktur beobachtet. Von ► * Beobachter Subjekt {abstract} 1. . * ◄ beobachtet - beobachtet : Subjekt - beobachtet. Von : List. Of. Beobachter #benachrichtigen() für alle beo in beobachtet. Von: +aktualisieren(. . . ) +registrieren(beob: Beobachter) beo. aktualisieren(. . . ); +löschen(beob: Beobachter) beobachtet. get. Meine. Daten(); . . . //aktualisiere zustand Client Mein. Subjekt -meine. Daten : Data +get. Meine. Daten(): Data +set. Meine. Daten(d: Data) set. Meine. Daten(x). . . i. Tec Mein. Beobachter - zustand. // bearbeite und. // aktualisiere. // meine. Daten benachrichtigen(); +aktualisieren(. . . ) 37

Beobachter/Observer 4. Patterns und Frameworks Teilnehmer q Subjekt kennt seine Beobachter (beliebig viele) als abstrakte Beobachter; bietet Schnittstelle zur (Ent)Registrierung von Beobachtern; hat Operation zur Benachrichtigung registrierter Beobachter q Beobachter bietet einen Typ (abstrakte Klasse/Interface) der benachrichtigt werden kann von Subjekten q Mein. Subjekt 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 q Mein. Beobachter ist abhängig und hält eine Referenz zu einem Mein. Subjekt-Objekt; enthält Daten die mit Daten des Subjekts konsistent sein müssen; 38 i. Tec implementiert die aktualisiere-Operation zur Benachrichtigung

Beobachter/Observer 4. Patterns und Frameworks Zusammenspiel q 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. entfernt sie. q nach jeder Veränderung schickt das Subjekt sich selbst die Nachricht benachrichtigen. Diese iteriert die Liste der Beobachter und schickt jedem Beobachter die Nachricht aktualisieren. Ggf. können Informationen (z. B. die Art des eingetretenen Ereignisses, oder das benachrichtigende Objekt selber) als Parameter mitgegeben werden. q jeder benachrichtigte Beobachter reagiert, indem er beim benachrichtigenden Sujekt mit get. XXX- Nachrichten die ihn interessierenden Informationen abruft. q alternativ können der aktualisiere-Nachricht die veränderten Daten gleich mitgegeben werden, wodurch der Abruf durch get. XXX entfällt. Dieses "Bring"-Prinzip ist effizient, koppelt aber Subjekt und Beobachter stärker als das mit get. XXX realisierte "Hol"-Prinzip. i. Tec 39

Beobachter/Observer 4. Patterns und Frameworks Zusammenspiel ms : Mein. Subjekt mb : Mein. Beobachter db : Dein. Beobachter registrieren mb registrieren db set. Meine. Daten benachrichtigen aktualisieren get. Meine. Daten Data i. Tec 40

Beobachter/Observer 4. Patterns und Frameworks Anwendbarkeit q 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 q wenn man also dynamische Abhängigkeiten hat q wenn man Abhängigkeiten in reinen Client/Server-Beziehungen modellieren möchte zwecks leichterer Änderbarkeit weiss von Serverklasse Clientklasse weiss nichts von i. Tec 41

Beobachter/Observer 4. Patterns und Frameworks Folgen q schwache, einseitige Kopplung zwischen unabhängiger und abhängigen Klassen: erstere kennt nur eine abstrakte Schnittstelle zur Benachrichtigung q sauberer Design: Aktualisierungslogik im abhängigen Teil, nicht im bestimmenden (nur benachrichtigen, nicht aktualisieren) q dadurch können die beiden Klassentypen zu unterschiedlichen Systemebenen gehören (nächste Folie) q unterstützt eine Art Broadcasting i. Tec 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-Komponente 1 GUI-Komponente 2 Klasse 1 GUI-Komponente 3 Klasse 2 Klassen der Anwendungslogikschicht verarbeiten Daten, ohne sie am Bildschirm zu präsentieren Anwendungslogikschicht Abhängigkeit i. Tec 43

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

Beobachter/Observer 4. Patterns und Frameworks lazy computing: erst dann berechnen, wenn Daten gebraucht werden Client get. Mein. Attribut() Mein. Beobachter -mein. Attribut: Typ //abhängiges Attr. -mein. Attribut. Status //valid/invalid +benachrichtige() +get. Mein. Attribut(): Typ get. Mein. Attribut() { if (mein. Attribut. Status == invalid) { beobachtet. get. Meine. Daten(); . . . //Neuberechnung von mein. Attribut. Status = valid; } return mein. Attribut; } i. Tec void benachrichtige() { mein. Attribut. Status = invalid; } Vorteil: weniger Berechnungen, falls Subjekt wesentlich öfter benachrichtigt als Beobachter befragt wird 45

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

Adapter 4. Patterns und Frameworks Struktur: Objektadapter Klient Ziel operation() adaptiert Adaptierte. Klasse spezifische. Operation() Adapter operation(). . . adaptiert. spezifische. Operation(). . . Adaption: q andere Operationensignatur – Operations- und Parameternamen, Parametertypen und -reihenfolge q andere Operationsfunktionen – ähnliche, aber nicht genau gleiche 47 i. Tec Semantik

Adapter 4. Patterns und Frameworks Adapter Beispiel: ein Zeicheneditor mit fremder Komponente Text. Anzeige Graphisches. Objekt 1 manipuliert * Zeicheneditor {abstract} zeichne() begrenzungsrahmen() begrenzungs. Rahmen() zeichne() Linie begrenzungs. Rahmen() zeichne() Text. Anzeige get. Ursprung() get. Hoehe() get. Breite() zeig. Mich() Kreis begrenzungs. Rahmen() zeichne() Text. Anzeige passt nicht zu Graphisches. Objekt: Problem für den Zeicheneditor i. Tec 48

Adapter 4. Patterns und Frameworks Adapter Beispiel: ein Zeicheneditor mit fremder Komponente Text. Anzeige einseitige Beziehung: Text. Anzeige auch ohne Source verwendbar 1 Text. Anzeige text get. Ursprung() get. Hoehe() get. Breite() zeig. Mich() Graphisches. Objekt {abstract} Zeicheneditor 1 manipuliert * zeichne() begrenzungsrahmen() zeichne() Linie begrenzungsrahmen() zeichne() Kreis begrenzungsrahmen() zeichne() Text begrenzungsrahmen() zeichne() begrenzungsrahmen() i. Tec text. get. Hoehe() text. get. Breite(). . . 1 zeichne(). . . text. zeig. Mich(). . . 49

Adapter 4. Patterns und Frameworks Struktur: Klassenadapter Klient Ziel Adaptierte. Klasse operation() spezifische. Operation() Adapter operation() benutzt Mehrfachvererbung i. Tec operation(). . . spezifische. Operation(). . . 50

Adapter 4. Patterns und Frameworks Folgen q Klassenadapter benutzt nur eine Objekt, während Objektadapter aus zwei bestehen q Objektadapter kann auch Objekte von Unterklassen der adaptierten Klasse adaptieren, was der Klassenadapter nicht kann i. Tec 51

Adapter 4. Patterns und Frameworks Implementation in JAVA: Objektadapter mit einem Interface class Was. Ich. Habe { public void g() {} public void h() {} } interface Was. Ich. Moechte { void f(); } class Was. Ich. Benutze { public void op(Was. Ich. Moechte wim) { wim. f(); } } Was. Ich. Benutze Was. Ich. Moechte Adapter i. Tec class Adapter implements Was. Ich. Moechte { //Referenz auf was adaptiert werden soll Was. Ich. Habe wasichhabe; //Konstruktor verbindet Adapter mit Was. Ich. Habe public Adapter(Was. Ich. Habe wih) { wasichhabe = wih; } public void f() { // Implementiert Methode mit den // Methoden in Was. Ich. Habe: wasichhabe. g(); wasichhabe. h(); } } Was. Ich. Habe 52

Kompositum 4. Patterns und Frameworks Zweck Füge Objekte zu Baumstrukturen zusammen, um Teil-Ganzes. Hierarchien zu repräsentieren. Das Kompositionsmuster ermöglicht es dem Klienten (Benutzer dieses Musters), sowohl einzelne Objekte als auch Kompositionen von Objekten einheitlich zu behandeln. Motivation viel verwendet in Grafik-Anwendungen und im Produktionsbereich (Produktbäume) i. Tec 53

Kompositum 4. Patterns und Frameworks Beispiel: Grafikeditor * Dokument Text Figur Linie i. Tec Blatt . . . Kreis 54

Kompositum 4. Patterns und Frameworks Beispiel: Grafikanwendung Grafik {abstract} zeichne() hinzufügen(Grafik) entfernen(Grafik) hole. Nächstes. Kind() * enthält Linie zeichne() Rechteck zeichne() Text zeichne() für alle g in "enthält": g. zeichne(); Gruppe zeichne() //Delegation!! hinzufügen(Grafik g) entfernen(Grafik) hole. Nächstes. Kind() füge g ein in "enthält" i. Tec 55

Kompositum i. Tec 4. Patterns und Frameworks 56

Kompositum 4. Patterns und Frameworks Rollen Komponente • Deklariert die Schnittstelle für Objekte in der zusammengefügten Struktur. • Implementiert, sofern angebracht, ein Defaultverhalten für die allen Klassen gemeinsame Schnittstelle (ist in JAVA dann abstrakte Klasse). • Deklariert eine Schnittstelle zum Zugriff auf und zur Verwaltung von Kindobjekten. • Definiert optional eine Schnittstelle zum Zugriff auf das Elternobjekt einer Komponente innerhalb der rekursiven Struktur und implementiert sie, falls dies angebracht erscheint. Blatt • Repräsentiert Blattobjekte in der Komposition. Ein Blatt besitzt keine Kindobjekte. • Definiert Verhalten für die primitiven Objekte in der Komposition. Kompositum • Definiert Verhalten für Komponenten, die Kindobjekte haben können. • Speichert Kindobjektkomponenten. • Implementiert kindobjekt-bezogene Operationen der Schnittstelle von Komponente. Klient 57 • Manipuliert die Objekte in der Komposition durch die Schnittstelle von Komponente. i. Tec

Kompositum 4. Patterns und Frameworks Verwendung Verwende das Kompositionsmuster, wenn • Teil-Ganzes-Hierarchien von Objekten repräsentiert werden sollen • klienten in der Lage sein sollen, die Unterschiede zwischen zusammengesetzten und einzelnen Objekten zu ignorieren. Klienten behandeln alle Objekte in der zusammengesetzten Struktur einheitlich. i. Tec 58

Singleton/Kompositum 4. Patterns und Frameworks Beispiel ein binärer Suchbaum: Entwurf als Kompositum und mit leerem Baum als Singleton q gewünscht: eine Klasse eines binären Suchbaums, dessen Objekte auch leer sein können: Binärbaum ohne Elemente q Anforderung: der leere Baum muss genauso ansprechbar sein wie ein nichtleerer binärer Suchbaum: also mit Operationen – is. Empty(), is. In(Object o), insert(Object o) q ein leerer Baum kann also nicht als Nullreferenz realisiert werden ! i. Tec 59

Singleton/Kompositum 4. Patterns und Frameworks ein binärer Suchbaum: «Interface» Entwurf als Kompositum Bin. Search. Tree und mit leerem Baum is. Empty(): boolean als Singleton is. In(Object o): boolean has. Father has. Child 0. . 2 insert(Object o): Bin. Search. Tree «Singleton» Empty. Tree empty: Empty. Tree is. Empty(): boolean is. In(Object o): boolean insert(Object o): Bin. Search. Tree i. Tec Node info: Object left. Child: Node right. Child: Node 0. . 1 is. Empty(): boolean is. In(Object o): boolean insert(Object o): Bin. Search. Tree 60

Singleton/Kompositum 4. Patterns und Frameworks ein binärer Suchbaum: Entwurf als Kompositum und mit leerem Baum als Singleton : Client. Class b= Empty. Tree. Instance() b = b. insert(o 1) b = b. insert(o 2) b = b. insert(o 3) i. Tec empty: Empty. Tree Instance() insert(o 1) new b: Node insert(o 2) {b. info < o 1} insert(o 3) {b. info > o 2} new b. left. Child: Node b. right. Child: Node 61

Singleton/Kompositum ein binärer Suchbaum: JAVA Code 4. Patterns und Frameworks public interface Bin. Search. Tree { boolean is. Empty(); boolean is. In(Object e); einzige Instanz als Klassenattribut Bin. Search. Tree insert(Object e); } //--------------------------------public class Empty. Tree implements Bin. Search. Tree { alle Konstruktoren sind damit privat public static Empty. Tree empty = new Empty. Tree(); private Empty. Tree() {} Benutzung: Instance() als "Konstruktor" gibt einziges empty als Empty. Tree-Objekt heraus hier wird aus dem einzigen Empty. Tree-Objekt jeweils ein neuer Baum erzeugt der nuri. Tec aus einer Wurzel besteht public static Empty. Tree Instance() { return empty; } public boolean is. Empty() { return true; } public boolean is. In(Object e) { return false; } public Bin. Tree insert(Object e) { return new Node(e); } } 62

Singleton/Kompositum 4. Patterns und Frameworks public class Node extends Bin. Search. Tree { protected Object info; protected Bin. Search. Tree left; protected Bin. Search. Tree right; public Node(Object info) { Kompositum: füge leere Bäume als Blätter ein this. info = info; left = Empty. Tree. Instance(); public Bin. Search. Tree insert(Object e) { switch ( info. compare. To(e) ) { case -1: left = left. insert(e); break; case 0: break; case +1: right = right. insert(e); break; } return this; right = Empty. Tree. Instance(); } public boolean is. Empty() { return false; } public boolean is. In(Object e) { switch ( info. compare. To(e) ) { case -1: return left. is. In(e); case 0: return true; case +1: return right. is. In(e); } return false; } i. Tec } } 63

Singleton/Kompositum Benutzung des binären Suchbaumes 4. Patterns und Frameworks public static void main( String args[ ] ) { Bin. Search. Tree tree = Empty. Tree. Instance(); tree = read. Tree( tree, "dateiname" ); . . . } public Bin. Search. Tree read. Tree( Bin. Search. Tree bst, String datei ) { int wert; // in einer Schleife werte einlesen. . . bst = bst. insert( Integer(wert) ); Achtung: falls ein leerer Baum übergeben wird, ändert sich. . . die Objektreferenz durch die } unser Binärbaum hat allgemeine Einfügung des ersten Knotens Knoten, die Informationen vom Typ Object halten (keine Templates!) Deshalb: Wrapperklasse um den Integerwert! i. Tec 64

Kompositum 4. Patterns und Frameworks wichtig beim Kompositum ist die Unterscheidung von Klassen- und Objektbäumen – das Kompositum generiert Objektbäume Klasse 11 obj. A obj. B Klasse 12 obj. D Klasse 121 obj. C obj. E obj. F Klasse 122 q Klassenbäume sind statische Vererbungshierarchien q Objektbäume sind dynamisch erzeugte Bäume mit Knotenobjekten i. Tec 65

Dekorierer 4. Patterns und Frameworks q Name: Dekorierer (decorator oder wrapper) q Absicht: füge einem Objekt dynamisch Zusatzfunktionalität hinzu q Problem: wenn man zu einer Basisfunktionalität wie Grafikdarstellung oder einer Ein-/Ausgabe vielfache Zusatzfunktionalität wie in einem Baukasten frei kombinierbar hinzufügen möchte, ergibt sich rasch eine kombinatorische Vielfalt, die man nur noch schwer in einer statischen Klassenstruktur darstellen und warten kann. q Lösungsidee: kombiniere die Zusatzfunktionalität dynamisch in einer Umhüllung in mehreren Schichten (Wrapper) um das ursprüngliche Objekt herum. Jede Hülle (Dekoriererklasse) kann genauso angesprochen werden wie das ursprüngliche Objekt i. Tec 66

Dekorierer 4. Patterns und Frameworks Struktur Komponente {abstract} 1 +operation() hat. Komponente Konkrete. Komponente Dekorierer +operation() Konkreter. Dekorierer. A +operation() #zusatz. Operation. A() i. Tec {abstract} Konkreter. Dekorierer. B +operation() #zusatz. Operation. B() . . . 67

Dekorierer 4. Patterns und Frameworks Zusammenspiel d. A: Konkreter. Dekorierer. A d. B: Konkreter. Dekorierer. B hat. Komponente operation() kp: Konkrete. Komponente zusatz. Operation. A() operation() zusatz. Operation. B() operation() i. Tec 68

Dekorierer 4. Patterns und Frameworks Beispiel Component {abstract} 1 . . . /*display text*/. . . +draw() has. Component Decorator{abstract} Text. View +draw() Wrapper: : draw() border. Draw() +draw() Border. Decorator +draw() #border. Draw() BW 1: Border. Decorator SW 1: Scroll. Decorator draw() i. Tec has. Component. draw() Scroll. Decorator +draw() #scroll. Draw() Wrapper: : draw() scroll. Draw() T 1: Text. View draw() 69

Dekorierer 4. Patterns und Frameworks Konsequenzen i. Tec 70

Zustand/State i. Tec 4. Patterns und Frameworks 71

Iterator 4. Patterns und Frameworks q Name: Iterator q Absicht stelle einen sequentiellen Zugriff auf die Elemente eines Behälterobjekts ohne dessen interne Darstellung zu veröffentlichen q Problem: Behälterobjekte i. Tec 72

Einführung 4. Patterns und Frameworks Merkmale zur Kennzeichnung von Frameworks q Werkzeug des Software-Entwicklers. q Wiederverwendbare, im Sinne einer Anwendung nicht fertige SWBausteine. q Frameworks definieren in ihrem Answendungsbereich die Systemarchitektur. q Frameworks definieren die Regeln, nach denen sie zur vollständigen Anwendung weiterentwickelt werden. q Frameworks enthalten eine wiederverwendbare, allgemeingültige und durch das Zusammenspiel einzelner Objekte des Frameworks vordefinierte Verarbeitungslogik. q Frameworks beeinflussen den gesamten Software. Entwicklungsprozess. q Frameworks sind objektorientiert implementiert. i. Tec 73

Datentypen II i. Tec 4. Gundbegriffe des Programmierens 74

Folgen i. Tec 5. Einfache Algorithmen 75