Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

ITec 1 Entwurfsmuster. iTec 2 Einführung: was ist und wozu braucht man Patterns u. Frameworks ? wie werden Patterns beschrieben ? Beispiele für Designpatterns.

Ähnliche Präsentationen


Präsentation zum Thema: "ITec 1 Entwurfsmuster. iTec 2 Einführung: was ist und wozu braucht man Patterns u. Frameworks ? wie werden Patterns beschrieben ? Beispiele für Designpatterns."—  Präsentation transkript:

1 iTec 1 Entwurfsmuster

2 iTec 2 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 Inhalt 4. Patterns und Frameworks

3 iTec 3 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 Einführung 4. Patterns und Frameworks was ist und wozu braucht man Patterns und Frameworks?

4 iTec 4 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 ! Einführung 4. Patterns und Frameworks Geschichte der Patterns

5 iTec 5 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 Einführung 4. Patterns und Frameworks

6 iTec 6 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. Einführung 4. Patterns und Frameworks 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 iTec 7 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 Einführung 4. Patterns und Frameworks

8 iTec 8 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 Y 2000-Problem Design Pattern eine Lösung für eine ganze Klasse von ähnlichen Problemen. Meistens erst sichtbar nach längerer Anwendung von Standard-Designs. Einführung 4. Patterns und Frameworks Pattern Einordnung

9 iTec 9 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 wie wird man ein guter Schachspieler? Einführung 4. Patterns und Frameworks

10 iTec 10 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 wie wird man ein guter Software-Designer? Einführung 4. Patterns und Frameworks

11 iTec 11 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. Pattern Beispiel: Singleton Einführung 4. Patterns und Frameworks Objekt in globaler Variablen keine Garantie für Einmaligkeit besser: lasse die Klasse selber ihren Konstruktor überwachen

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

14 iTec 14 Beispiel: Singleton (JAVA) Einführung 4. Patterns und Frameworks 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; } } 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()); } Ausgabe: 99 9

15 iTec 15 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 vonStrukturmustern beschriebenen Strukturen entstehen zur Laufzeit, beruhen also auf der Technik der dynamischen Objektkomposition Einführung 4. Patterns und Frameworks es gibt drei Pattern Typen

16 iTec 16 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. Einführung 4. Patterns und Frameworks es gibt drei Pattern Typen

17 iTec 17 Einführung 4. Patterns und Frameworks

18 iTec 18 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 Einführung 4. Patterns und Frameworks Vorteile von Entwurfsmustern

19 iTec 19 Name den 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 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. Lösungsidee skizziert, wie das Muster aussehen könnte, mit dem das im vorigen Abschnitt beschriebene Problem gelöst werden könnte. Struktur wird in einem UML Diagramm angegeben, das die statische Struktur der beteiligten Klassen verdeutlicht. Die Beteiligten Hier werden die beteiligten Klassen noch einmal in Worten aufgezählt und ihre Rollen ausführlicher beschrieben. Patternbeschreibung 4. Patterns und Frameworks

20 iTec 20 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. Anwendbarkeit beschreibt Situationen, in denen das Muster sinnvoll eingesetzt werden kann, bzw. die Bedingungen, die gelten müssen, damit es eingesetzt werden kann. Folgen beschreibt die Vor- und Nachteile, die dieses Muster mit sich bringt. Implementation diskutiert Aspekte, die bei Implementation des Musters zu bedenken sind Codebeispiele gibt konkrete Implementationen des Musters an anhand eines typischen Problems, in den wichtigsten OO-Sprachen (JAVA, C++) Bekannte Anwendungen (bekannt!) Verwandte Muster geht auf Beziehungen zwischen diversen Mustern ein; es ist selten so, daß eine Problemklasse nur durch ein einziges Muster allein entschärft wird. Patternbeschreibung 4. Patterns und Frameworks

21 iTec 21 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. Proxy 4. Patterns und Frameworks

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

23 iTec 23 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 Proxy 4. Patterns und Frameworks

24 iTec 24 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 Proxy 4. Patterns und Frameworks

25 iTec 25 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 Proxy 4. Patterns und Frameworks Folgen

26 iTec 26 Proxy 4. Patterns und Frameworks

27 iTec 27 interface Subjekt { int getA(); float getB(); } class Proxy implements Subjekt { private EchtesSubjekt vertritt; // delegiere Methodenaufrufe an EchtesS: public int getA() { return getEchtesSubjekt().getA(); } public float getB() { return getEchtesSubjekt().getB(); } protected EchtesSubjekt getEchtesSubjekt() { if ( vertritt == null ) vertritt = new EchtesSubjekt(); return vertritt; } Proxy 4. Patterns und Frameworks 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() ); } Beispiel in Java: virtueller Proxy lazy initialization

28 iTec 28 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: Zustand/State 4. Patterns und Frameworks Datei dateiname : String oeffnen() schliessen() weitereOp() OffeneDatei oeffnen() schliessen() GeschlosseneDatei oeffnen() schliessen() Datei dateiname : String offen : boolean oeffnen() schliessen() weitereOp() Spezialisierung Problem: ein Dateiobjekt müsste seine Klasse wechseln können

29 iTec 29 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 Zustand/State 4. Patterns und Frameworks 1 KlasseMitZustand opAbhängig() opUnabhängig() Zustand {abstract} opAbhängig() ZustandA opAbhängig() ZustandB opAbhängig()... operation() { state.opAbhängig(); } state Zustandsänderung: - wie wird er geändert ? - wer bzw. wo wird ein Zustand geändert ?

30 iTec 30 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 Zustand/State 4. Patterns und Frameworks Rollen

31 iTec 31 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 Zustand/State 4. Patterns und Frameworks Anwendbarkeit:

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

33 iTec 33 ComplexClass... actState : State act : Action... StateTransitionTable 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) 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... hasSTT 1..* 1 Zustand/State 4. Patterns und Frameworks

34 iTec 34 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 Zustand/State 4. Patterns und Frameworks Konsequenzen

35 iTec 35 Name: Beobachter (Observer) 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. 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 von Informationsverarbeitern bzw. Darstellern der Information. Die Bereitsteller müssen die Verarbeiter nicht direkt kennen: statt direkter Kommunikation über Aufrufe benutze eine indirekte über Benachrichtigungen. Beobachter/Observer 4. Patterns und Frameworks

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

37 iTec 37 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 Beobachter/Observer 4. Patterns und Frameworks

38 iTec 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. entfernt sie. 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. jeder benachrichtigte Beobachter reagiert, indem er beim benach- richtigenden Sujekt mit getXXX- Nachrichten die ihn interessierenden Informationen abruft. alternativ können der aktualisiere-Nachricht die veränderten Daten gleich mitgegeben werden, wodurch der Abruf durch getXXX entfällt. Dieses "Bring"-Prinzip ist effizient, koppelt aber Subjekt und Beobachter stärker als das mit getXXX realisierte "Hol"-Prinzip.

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

40 iTec 40 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 Anwendbarkeit Beobachter/Observer 4. Patterns und Frameworks Clientklasse Serverklasse weiss von weiss nichts von

41 iTec 41 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 Beobachter/Observer 4. Patterns und Frameworks Folgen

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

43 iTec 43 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 Beobachter/Observer 4. Patterns und Frameworks Implementation

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

45 iTec 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( Beobachter beob ) { for ( int i = 0; i < anzBeobachter; ++i ) { if (beobachtetVon[i] == beob) { - - observerCnt; for ( ; i < anzBeobachter; ++i) beobachtetVon[ i ] = beobachtetVon[ i + 1 ]; break; }

46 iTec 46 Adapter 4. Patterns und Frameworks Name: Adapter Absicht erlaubt die Zusammenarbeit von Klassen die unterschiedliche Schnitt- stellen haben. Adapter wird als verbindendes Element zwischen die beiden Klassen eingefügt. 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. 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

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

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

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

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

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

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

53 iTec 53 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)

54 iTec 54 Kompositum 4. Patterns und Frameworks Dokument Blatt * TextFigur Linie Kreis... Beispiel: Grafikeditor

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

56 iTec 56 Kompositum 4. Patterns und Frameworks

57 iTec 57 Kompositum 4. Patterns und Frameworks 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 Manipuliert die Objekte in der Komposition durch die Schnittstelle von Komponente. Rollen

58 iTec 58 Kompositum 4. Patterns und Frameworks 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. Verwendung

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

60 iTec 60 Singleton/Kompositum 4. Patterns und Frameworks «Interface» BinSearchTree isEmpty(): boolean isIn(Object o): boolean insert(Object o): BinSearchTree «Singleton» EmptyTree empty: EmptyTree isEmpty(): boolean isIn(Object o): boolean insert(Object o): BinSearchTree Node info: Object leftChild: Node rightChild: Node isEmpty(): boolean isIn(Object o): boolean insert(Object o): BinSearchTree hasFather hasChild ein binärer Suchbaum: Entwurf als Kompositum und mit leerem Baum als Singleton

61 iTec 61 empty:EmptyTree :ClientClass Instance() insert(o1) b:Node b = EmptyTree.Instance() new b = b.insert(o1) b = b.insert(o2) insert(o2) b.leftChild:Node new b = b.insert(o3) insert(o3) b.rightChild:Node new {b.info < o1} {b.info > o2} Singleton/Kompositum 4. Patterns und Frameworks ein binärer Suchbaum: Entwurf als Kompositum und mit leerem Baum als Singleton

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

63 iTec 63 public class Node extends BinSearchTree { protected Object info; protected BinSearchTree left; protected BinSearchTree right; public Node(Object info) { this.info = info; left = EmptyTree.Instance(); right = EmptyTree.Instance(); } public boolean isEmpty() { return false; } public boolean isIn(Object e) { switch ( info.compareTo(e) ) { case -1: return left.isIn(e); case 0: return true; case +1: return right.isIn(e); } return false; } public BinSearchTree insert(Object e) { switch ( info.compareTo(e) ) { case -1: left = left.insert(e); break; case 0: break; case +1: right = right.insert(e); break; } return this; } Singleton/Kompositum 4. Patterns und Frameworks Kompositum: füge leere Bäume als Blätter ein Kompositum: füge leere Bäume als Blätter ein

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

65 iTec 65 Kompositum 4. Patterns und Frameworks wichtig beim Kompositum ist die Unterscheidung von Klassen- und Objektbäumen – das Kompositum generiert Objektbäume Klasse1 Klasse12 Klasse11 Klasse122 Klasse121 objA objC objB objE objD objF Klassenbäume sind statische Vererbungshierarchien Objektbäume sind dynamisch erzeugte Bäume mit Knotenobjekten

66 iTec 66 Name: Dekorierer (decorator oder wrapper) Absicht: füge einem Objekt dynamisch Zusatzfunktionalität hinzu Problem: wenn man zu einer Basisfunktionalität wie Grafikdar- stellung 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. 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 Dekorierer 4. Patterns und Frameworks

67 iTec 67 Dekorierer +operation() KonkreterDekoriererA +operation() #zusatzOperationA() +operation() #zusatzOperationB() {abstract} Komponente +operation() {abstract} 1 hatKomponente KonkreteKomponente +operation() KonkreterDekoriererB... Struktur Dekorierer 4. Patterns und Frameworks

68 iTec 68 Dekorierer 4. Patterns und Frameworks Zusammenspiel kp:KonkreteKomponente dA:KonkreterDekoriererA hatKomponente dB:KonkreterDekoriererB hatKomponente operation() zusatzOperationA() operation() zusatzOperationB() operation()

69 iTec 69 Decorator +draw() BorderDecorator +draw() #borderDraw() ScrollDecorator +draw() #scrollDraw() Wrapper::draw() scrollDraw() {abstract} Component +draw() {abstract} 1 hasComponent TextView +draw() SW 1 :ScrollDecorator draw() BW 1 :BorderDecorator draw() T 1 :TextView draw() hasComponent.draw() Wrapper::draw() borderDraw()... /*display text*/... Beispiel Dekorierer 4. Patterns und Frameworks

70 iTec 70 Dekorierer 4. Patterns und Frameworks Konsequenzen

71 iTec 71 Zustand/State 4. Patterns und Frameworks

72 iTec 72 Name: Iterator Absicht stelle einen sequentiellen Zugriff auf die Elemente eines Behälter- objekts ohne dessen interne Darstellung zu veröffentlichen Problem: Behälterobjekte Iterator 4. Patterns und Frameworks

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

74 iTec 74 Datentypen II 4. Gundbegriffe des Programmierens

75 iTec 75 Folgen 5. Einfache Algorithmen


Herunterladen ppt "ITec 1 Entwurfsmuster. iTec 2 Einführung: was ist und wozu braucht man Patterns u. Frameworks ? wie werden Patterns beschrieben ? Beispiele für Designpatterns."

Ähnliche Präsentationen


Google-Anzeigen