Seminar Software Design Pattern



Ähnliche Dokumente
Ein Entwurfsmuster der GoF. vorgestellt von. Sigrid Weil 16. Januar 2008

Creational Patterns. Seminar Software-Entwurf. Thomas Liro WS 2004/05.

Factory Patterns und deren Auswirkung auf die Softwarearchitektur in der Praxis

Design Patterns II. Der Design Muster Katalog. Prof. Dr. Nikolaus Wulff

Überblick FBC SNW Zusammenfassung. Entwurfsmuster. Eine Einführung. Botond Draskoczy. Marcus Vitruvius Pollio

Software Design Patterns Zusammensetzung. Daniel Gerber

185.A Software-Entwurfsmuster 1 OOP. Software-Entwurfsmuster

Design Patterns. (Software-Architektur) Prof. Dr. Oliver Braun. Letzte Änderung: :12. Design Patterns 1/26

Erzeugungsmuster. Kapselung der Objekt-Erzeugung

Design Patterns. 3. Juni 2015

Design Patterns I. Observer, Listener & MVC

Software-Architektur. Design Patterns. Prof. Dr. Oliver Braun. Fakultät für Informatik und Mathematik Hochschule München

Daniel Warneke Ein Vortrag im Rahmen des Proseminars Software Pioneers

Zweck: sequentieller Zugriff auf Elemente eines Aggregats

DESIGN'PATTERN'2011. November. Abstract Factory & Factory Method BEARBEITET VON INHALT [1] Christoph Süsens

Software-Entwurfsmuster

Factory Method (Virtual Constructor)

Entwurfsmuster (Design Patterns)

Factory Method Pattern

Design Patterns. OO-GetTogether. Volker Michels

Software Engineering II (IB) Design Patterns

Strategy & Decorator Pattern

Analyse und Modellierung von Informationssystemen

Analyse und Modellierung von Informationssystemen

Entwurfsmuster Martin Fesser 00IN

Software Engineering II (IB) Design Patterns

Universität Bremen. Entwurfsmuster. Thomas Röfer. Wettbewerb Motivation Erzeugende Muster Strukturelle Muster Verhaltensmuster

Objektorientierte und Funktionale Programmierung SS 2014

Head First Design Patterns. FALLBEISPIEL: SimUDuck

Software-Entwurfsmuster

Verhaltensmuster. Entwurfsmuster - Design Patterns. HAW Hamburg Fakultät Technik und Informatik Department Informations- und Elektrotechnik

Übersicht. Softwarearchitektur. Softwarearchitektur, UML, Design Patterns und Unit Tests. Softwarearchitektur

Specifying Patterns for Dynamic Pattern Instance Recognition with UML 2.0 Sequence Diagrams. Lothar Wendehals. Universität Paderborn

Das Zustandsmuster Eine Einführung

Softwarearchitektur, UML, Design Patterns und Unit Tests

Entwurfsmuster Design Patterns by Erich Gamma et al.

MVVM (Model View ViewModel) in JavaFX

Structural Patterns. B. Sc. Andreas Meißner

Design Pattern. Motivation, Beispiel Definition "Das" Buch der Gang of Four Ausführliches Beispiel: Facade Beispiele. Aufgabe

Software-Architektur Design Patterns

class Mitarbeiter {...} class AussendienstMitarbeiter extends Mitarbeiter {...} class InnendienstMitarbeiter extends Mitarbeiter {...

Wahlpflichtfach Design Pattern

Informatik II Übung 06. Benjamin Hepp 5 April 2017

Aufgabenblatt 4. Aufgabe 3. Aufgabe 1. Aufgabe 2. Prof. Dr. Th. Letschert Algorithmen und Datenstrukturen

Entwurfsmuster. Marc Monecke

Inhaltsverzeichnis. Vorwort Geleitwort von Grady Booch Einleitung... 23

3. Entwurfsmuster zur Entkopplung von Modulen

Einstieg in die Informatik mit Java

Entwurfsmuster - Iterator & Composite

Model-View-Controller

Design-Patterns-Katalog

Lukas Klich. Projektgruppe SHUTTLE. Seminar: Entwurfsmuster Lukas Klich/Projektgruppe SHUTTLE Seite: 1. Entwurfsmuster

Tutorium Softwaretechnik I

Behavioral Patterns. Seminar Software-Entwurf WS 04/05. Przemyslaw Dul

Schlussendlich geben wir die Listen aus. Es kommt zu folgender Ausgabe:

Softwaretechnik. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen

Entwurfsmuster. Tao Zhang Technische Universität München Lehrstuhl für Angewandete Softwaretechnik

Observer Chain of Responsibility Mediator

Theorie zu Übung 8 Implementierung in Java

Decorator Pattern. Analyse- und Design-Pattern CAS SWE FS14. Roland Müller Samuel Schärer

Refaktorisierung des Eclipse- Plugins Saros für die Portierung auf andere IDEs. Verteidigung der Bachelorarbeit von Arndt Tigges

Web Engineering-Seminar Methoden zur Web Modellierung: Object-oriented Hypermedia Method (OO-H)

3. Entwurfsmuster zur Entkopplung von Modulen. Übersicht zu Entwurfsmustern

Programmieren in Java -Eingangstest-

Strategie. (Strategy. / Policy) Ein objektbasiertes Verhaltensmuster. Stephan Munkelt, Stefan Salzmann - 03IN

Informatik II Übung 6 Gruppe 7

Software-Engineering im Sommersemester 2014

Komponentenbasierter

Kapitel 9. Programmierkurs. Attribute von Klassen, Methoden und Variablen. 9.1 Attribute von Klassen, Methoden und Variablen

FH D. Objektorientierte Programmierung in Java FH D FH D. Prof. Dr. Ing. André Stuhlsatz. Wiederholung: Gerüstbeispiel. Vererbungshierarchie: Typ 0

Entwurfsprinzip. Entwurfsprinzip

Anwendungsentwicklung mit Java. Grundlagen der OOP, Vererbung, Schnittstellen, Polymorphie

Informatik II. Übungsstunde 6. Distributed Systems Group, ETH Zürich

~±] Inhalt. 1.1 Ähnlichkeiten zwischen C# und Java Unterschiede zwischen C# und Java Das.NET-Framework 4 1.

Middleware für Verteilte Informationssysteme

Software Engineering. 10. Entwurfsmuster II. Franz-Josef Elmer, Universität Basel, HS 2015

Einführung in die Informatik II

Transkript:

Seminar Software Design Pattern Factory Method, Abstract Factory, Prototype Betriebliche Informationssysteme Institut für Informatik Universität Leipzig 13.05.2009

Gliederung 1 Design Pattern 2 Problembeispiel 3 Factory Method 4 Abstract Factory 5 Prototype

Gang of Four[Gamma et al., 1995] Lösung-Schablonen für Entwicklungsprobleme Design Patterns - Elements of Reusable Object-Oriented Software James Coplien, Richard Helm, Ralph Johnson, John Vlissides

Patternklassen der GoF Erzeugende Muster (Creational Patterns) Strukturelle Muster (Structural Patterns) Verhaltensmuster (Behavioral Patterns) weitere Patternklassen Architekturmuster Analysemuster Idiome Kommunikationsmuster Organisationsmuster Antimuster

nur genannt Singelton nur einmal erzeugtes Objekt Fewton Anzahl der erzeugten Objekte kontrolliert Builder Erzeugung komplexer Objekte im weiteren Vortrag Factory Methode Abstract Factory Prototype

Beispiel Entwicklung eines Framework für E-Assessment Einsatz mit unterschiedlichen JAVA Frameworks unterschiedliche Aufgabentypen unterschiedliche Repräsentationen unterschiedliche Persistenzschichten

Factory Method

Factory Method Kontext Implementierung von Frameworks/Klassenbibliotheken Interfaces zur Erzeugung von Objekten Definieren Beziehungen zwischen Objekten durch abstrakte Klassen

TaskFactory Tasklets SubTasklet -Tasklets: List Subtasklet st = newsubtasklet(); +build(): void +buildsubtask(): Task Tasklets.add(st); +buildpreview(): void +savetasklet(st:subtasklet): void st.build(); +getproblem(): String +newsubtasklet(): SubTasklet ClozeSubtasklet McSubtasklet MyTaskFactoryImpl

TaskFactory Tasklets SubTasklet -Tasklets: List Subtasklet st = newsubtasklet(); +build(): void +buildsubtask(): Task Tasklets.add(st); +buildpreview(): void +savetasklet(st:subtasklet): void st.build(); +getproblem(): String +newsubtasklet(): SubTasklet ClozeSubtasklet McSubtasklet MyTaskFactoryImpl Problem Instanzerzeugung Implementierungsäbhängig TaskFactory kennt die Subklassen von SubTasklet nicht TaskFactory weiß nur wann nicht welches SubTasklet Framework kennt nur die abstrakte Klasse nicht instanzierbar

Lösungsansatz newsubtasklet abstrakte Methode mögliche Defaultimplementierung Implementierung in Anwendung

Lösungsansatz newsubtasklet abstrakte Methode mögliche Defaultimplementierung Implementierung in Anwendung SubTasklet +build(): void +buildpreview(): void +getproblem(): String Tasklets TaskFactory +buildsubtask(): Task +savetasklet(st:subtasklet): void +newsubtasklet(): SubTasklet Subtasklet st = newsubtasklet(); Tasklets.add(st); st.build(); ClozeSubtasklet McSubtasklet MyTaskFactoryImpl +newsubtasklet(): Subtasklet return new McSubtasklet;

Charakteristik Implementation von newsubtasklet() in MyTaskFactoryImpl Kenntnis der Subklasse aus Framework entfernt newsubtasklet() wird Factory Methode genannt sie erstellt das Objekt SubTasklet +build(): void +buildpreview(): void +getproblem(): String Tasklets TaskFactory +buildsubtask(): Task +savetasklet(st:subtasklet): void +newsubtasklet(): SubTasklet Subtasklet st = newsubtasklet(); Tasklets.add(st); st.build(); ClozeSubtasklet McSubtasklet MyTaskFactoryImpl +newsubtasklet(): Subtasklet return new McSubtasklet;

Elemente des Patterns Produkt (Interface) KonkretesProdukt (Implementation zu Produkt) Erzeuger (Applikationsklasse) KonkreterErzeuger (spezielle Applikationsklasse) Produkt Erzeuger +FabrikMethode() +anoperation()... produkt = Fabrikmethode();... KonkretesProdukt KonkreterErzeuger +FabrikMethode() return new KonkretesProdukt; Abbildung: GoF Book S. 122

Anwendung und Konsequenz Erzeugerklasse kennt Objekttyp Subklassen sollen Typ bestimmen Client muss Subklasse von Creator sein Produkt Erzeuger +FabrikMethode() +anoperation()... produkt = Fabrikmethode();... KonkretesProdukt KonkreterErzeuger +FabrikMethode() return new KonkretesProdukt; Abbildung: GoF Book S. 122

Vorteile keine Bindung indirekte Objekterzeugung Defaultimplementierung parallele Objektstrukturen verknüpft

Vorteile keine Bindung indirekte Objekterzeugung Defaultimplementierung parallele Objektstrukturen verknüpft Nachteile Client Subklasse von Creator

Abstract Method

Abstract Method Kontext Framework stellt Struktur Framework soll implementierungsunabhängig sein Implementierung konfigurierbar austauschbar

HtmlSubTaskView +createmcsubtasklet() StrutsSubTaskView +createmcsubtasklet() Client +createclozesubtasklet() +createclozesubtasklet() ClozeSubTasklet HtmlClozeSubTasklet StrutsClozeSubTasklet MCSubTasklet HtmlMCSubTasklet StrutsMCSubTasklet

HtmlSubTaskView +createmcsubtasklet() StrutsSubTaskView +createmcsubtasklet() Client +createclozesubtasklet() +createclozesubtasklet() ClozeSubTasklet HtmlClozeSubTasklet StrutsClozeSubTasklet MCSubTasklet HtmlMCSubTasklet StrutsMCSubTasklet Problem ein Framework für Erstellung von Tests unterschiedliche Präsentationsframeworks Client muss die Implementierung kennen Präsentationsschichten sollten austauschbar sein

Lösungsansatz Client benutzt nur Interface Interface für SubTaskView mit Methoden für Objekterzeugung Implementierungen von SubTaskView Interfaces für Objekte

Lösungsansatz Client benutzt nur Interface Interface für SubTaskView mit Methoden für Objekterzeugung Implementierungen von SubTaskView Interfaces für Objekte SubTaskView +createmcsubtasklet() +createclozesubtasklet() MCSubTasklet Client HtmlMCSubTasklet StrutsMCSubTasklet HtmlSubTaskView +createmcsubtasklet() +createclozesubtasklet() StrutsSubTaskView +createmcsubtasklet() +createclozesubtasklet() ClozeSubTasklet HtmlClozeSubTasklet StrutsClozeSubTasklet

Charakteristik Client benutzt nur Interfaces Implementierungen erzeugen Objekte SubTaskView +createmcsubtasklet() +createclozesubtasklet() MCSubTasklet Client HtmlMCSubTasklet StrutsMCSubTasklet HtmlSubTaskView +createmcsubtasklet() +createclozesubtasklet() StrutsSubTaskView +createmcsubtasklet() +createclozesubtasklet() ClozeSubTasklet HtmlClozeSubTasklet StrutsClozeSubTasklet

Elemente des Patterns AbstrakteFactory KonkreteFactory AbstraktesProdukt KonkretesProdukt Client AbstrakteFactory +createprodukta() +createproduktb() AbstraktesProduktA Client ProduktA1 ProduktA2 KonkrekteFactory1 +createprodukta() +createproduktb() KonkrekteFactory1 +createprodukta() +createproduktb() AbstraktesProduktB ProduktB1 ProduktB2 Abbildung: GoF Book S. 101

Anwendung und Konsequenz KonkreteFactory meist Singelton ermöglicht Produktfamilien leichter Austausch von Implementierungen Versteckt Implementierung vor Client AbstrakteFactory +createprodukta() +createproduktb() AbstraktesProduktA Client ProduktA1 ProduktA2 KonkrekteFactory1 +createprodukta() +createproduktb() KonkrekteFactory1 +createprodukta() +createproduktb() AbstraktesProduktB ProduktB1 ProduktB2 Abbildung: GoF Book S. 101

Vorteile isoliert Implementierung Kontrolle der Objektgenerierung einfacher Austausch Konsistenz

Vorteile isoliert Implementierung Kontrolle der Objektgenerierung einfacher Austausch Konsistenz Nachteile neue Klassen kosten viel Aufwand

Prototype

Prototype Kontext Objekte im laufenden System spezifizieren Funktionalität nutzen spezifische Erweiterung[Pree, 1995] geringe Objektdifferenz keine komplexe Objekthierachie

SubTaskFactory NSubtaskFactory +buildtask() +buildtask() AddOnSubTask +build() AddonSubTaskImplA +build() AddonSubTaskImplB +build()

SubTaskFactory NSubtaskFactory +buildtask() +buildtask() AddOnSubTask +build() AddonSubTaskImplA +build() AddonSubTaskImplB +build() Problem Erweiterung um neue Objekte dynamisches Laden von Objekten Objektgenerierung parametrisieren Integration in bestehende Struktur

Lösungsansatz Einführung Factorysubklasse AddOnsubtaskFactory benutzt Prototyp Objektgenerierung mit Parameter AddOnSubTask Klonmethode Implementierung in Subklassen

Lösungsansatz Einführung Factorysubklasse AddOnsubtaskFactory benutzt Prototyp Objektgenerierung mit Parameter AddOnSubTask Klonmethode Implementierung in Subklassen SubTaskFactory +buildtask() AddOnSubTask +build(number) +clone() prototype NSubtaskFactory +buildtask() AddOnSubtaskFactory +buildtask() AddonSubTaskImplA +build(number) +clone() AddonSubTaskImplB +build(number) +clone() p=prototype.clone(); do p.build(random()); return the Clone; return the Clone; while(1=1) buildtask();

Charakteristik Prototypklassen haben Clone() meist mit Parameter SubTaskFactory +buildtask() AddOnSubTask +build(number) +clone() prototype NSubtaskFactory +buildtask() AddOnSubtaskFactory +buildtask() AddonSubTaskImplA +build(number) +clone() AddonSubTaskImplB +build(number) +clone() p=prototype.clone(); do p.build(random()); return the Clone; return the Clone; while(1=1) buildtask();

Elemente des Patterns Prototype (Klone Interface) ConcretePrototype (Klone Implementierung) Client Abbildung: GoF Book S. 135

Anwendung und Konsequenz Verringerung der Klassenanzahl Versteckt Implementierung vor Client Abbildung: GoF Book S. 135

Vorteile isoliert Implementierung weniger Objektklassen dynamische Binden neue Objekte einfach Parameter für Objekterstellung komplexe Objekte weniger Subklassen

Vorteile isoliert Implementierung weniger Objektklassen dynamische Binden neue Objekte einfach Parameter für Objekterstellung komplexe Objekte weniger Subklassen Nachteile Klone Methode aufwendig zu implementieren

Literatur Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements od Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York, NY. Pree, W. (1995). Design Patterns for Object-Oriented Software Development. ACM Press Books. Addison-Wesley Publishing Company, Wokingham.

vielen Dank für die Aufmerksamkeit Fragen??