Structural Patterns - se.uni-hannover.de · Structural Patterns B. Sc. Andreas Meißner Seminar...

StructuralStructural PatternsPatternsB. Sc. Andreas Meißner

Seminar Software-EntwurfFachgebiet Software Engineering, Institut für Angewandte Systeme,

Universität Hannover

11/16/2004

2B. Sc. Andreas Meißner: Strukturmuster

GliederungGliederung

1. Wiederholung Entwurfsmuster

2. Strukturmuster- Allgemein- einzelne Strukturmuster

- Beispiel (Motivation)- allgemeiner Aufbau- evtl. Diskussion / Abgrenzung

3. Fazit


EntwurfsmusterEntwurfsmuster

„Entwurfsmuster sind Beschreibungen zusam-menarbeitender Objekte und Klassen, die maß-geschneidert sind, um ein allgemeines Entwurfs-problem in einem bestimmten Kontext zu lösen.“

• Schablonen für guten Entwurf• benennen, abstrahieren und identifizieren relevante Aspekte

einer allgemeinen Entwurfsstruktur

• Ziel: bessere Flexibilität, Wiederverwendbarkeit, Modularität und Verständnis eines Entwurfs


EntwurfsmusterEntwurfsmuster

Aufgabe Entwurfsmuster

Creational Patterns(Erzeugungsmuster)

Abstract Factory (Abstrakte Fabrik), Builder (Erbauer),Factory Method (Fabrikmethode), Prototype (Prototyp),Singleton

Structural Patterns(Strukturmuster)

Adapter, Bridge (Brücke), Composite (Kompositum), Decorator (Dekorierer), Facade (Fassade), Flyweight (Fliegengewicht), Proxy

Behavioral Patterns(Verhaltensmuster)

Observer (Beobachter), Command (Befehl), Chain of Responsibility (Zuständigkeitskette), Interpreter,Iterator, Mediator (Vermittler), Memento, State (Vermittler), Strategy (Strategie),Template Method (Schablonenmethode), Visitor (Besucher),


StrukturmusterStrukturmuster

„Strukturmuster befassen sich mit der Zusammen-setzung bzw. Komposition von Klassen und Objekten, um größere Strukturen zu bilden.“

• bei klassenbasierten Strukturmustern wird Vererbung benutzt, um Schnittstellen oder Implementierungen zusammenzuführen

• bei objektbasierte Strukturmuster werden Objekte zusammengeführt, um neue Funktionalität zu gewinnen


Willis Willis BurgerShopBurgerShop

Willi


Problem No. 1Problem No. 1

• Implementation von Willi


Problem No. 1 Problem No. 1 -- LLöösungsung

• Variante 1: Vererbung • Variante 2: Delegation


Adapter Adapter ((WrapperWrapper))

• passt Schnittstelle einer Klasse an eine andere (erwartete) an• lässt Klassen zusammenarbeiten, die wegen inkompatibler Schnittstellen

dazu nicht in der Lage wären

• Klassenadapter

• lediglich ein Objekt• Methoden können überschrieben werden• Schnittstelle des Adapters evtl. größer als

benötigt• nicht immer möglich

• Objektadapter

• zusätzliches (delegierendes) Objekt• Adapter kann an mehrere Adaptees

anbinden


Wiederholung Wiederholung –– SingletonSingleton

• Willi ist „einzigartig“ !!!

public class Willi implements Angestellter {

private static Willi singleton = null;

public static Willi createWilli() {if (singleton == null)

return new Willi();return singleton;

}

private Willi() {…

}

public void buletteBraten {…}public void kaffeeKochen {…}public void sauberMachen {…}

}



• Implementation der BurgerShop-Geräte


FacadeFacade (Fassade)(Fassade)

• vereinfacht die Verwendung von (Sub-)Systemen• bietet einheitliche Schnittstelle zu einer Menge von Schnittstellen eines

(Sub-)Systems

• Konsequenzen:– Subsystem kann unabhängig von den Klienten angepasst werden– Funktionalität der Subsystemkomponenten kann nicht endgültig verborgen

werden


Adapter vs. Adapter vs. FacadeFacade

• Unterschied zwischen Adapter und Fassade ist subtil

Frage Adapter FacadeGibt es bereits existierende Klassen mit unpassender Schnittstelle?

Wird ein Objekt erzeugt, welches die gewünschte Schnittstelle aufweist?

Muss dieses Objekt polymorph verwendet werden können?

Gibt es Vorgabe für eine Schnittstelle, die erfüllt werden müssen?

Ist eine vereinfachte Schnittstelle notwendig?

JaJa

Ja Ja

Möglich Nein

Ja Nein

Nein Ja



• Implementation der Burger

+

+

+



• jede Garnierung als Dekoration betrachten



Burger burger = new TomatenDekorierer(new SalatDekorierer(

new KaeseDekorierer(new Hamburger())));


DecoratorDecorator (Dekorierer)(Dekorierer)

• erweitert Objekte dynamisch um Zuständigkeiten• flexible Alternative zur Unterklassenbildung

• Konsequenzen– mehrfaches Hinzufügen der Funktionalität möglich– Objektidentität des Dekorierers und dessen Komponente ist unterschiedlich– viele kleine Dekorierobjekte möglich Entwurf evtl. schwerer zu verstehen


Wiederholung Wiederholung –– BuilderBuilder (Erbauer)(Erbauer)

Burger burger = new TomatenDekorierer(new SalatDekorierer(

new KaeseDekorierer(new Hamburger())));

BurgerBuilder bb = new BurgerBuilder();bb.startBurger();bb.addKaese();bb.addSalat();bb.addTomate();Burger burger = bb.getResult();

public class BurgerBuilder {

private Burger burger = null;

public void startBurger() {burger = new Hamburger();

}

public void addKaese() {burger = new KaeseDekorierer(burger);

}

public void addSalat() {burger = new SalatDekorierer(burger);

}

public void addTomate() {…}

public Burger getResult() {return burger;

}}



• Implementation von Menus


CompositeComposite (Kompositum)(Kompositum)

• repräsentiert Teil-Ganzes-Hierarchien• primitive Objekte und Kompositionen von diesen können

einheitlich betrachtet werden

• Konsequenzen– unbegrenzte Tiefe/Komplexität möglich– Komponenten eines Kompositums sind schwierig einschränkbar– Implementationsfragen (Schnittstellen, Elternobjekte referenzieren)


DekoratorDekorator vs. vs. CompositeComposite

• Dekorierer kann als degeneriertes Kompositum angesehen werden

• aber– Dekorierer fügt zusätzliche Funktionalität hinzu– Kompositum ist für Objektaggregation vorgesehen



• Implementation der Anzeigetafel



• jedes Zeichen als eigenes Objekt• Problem: hohe Speicherkosten

• jedes Zeichen einmal vorhanden gemeinsame Nutzung • Trennung des intrinsischen und extrinsischen Zustandes

notwendig


FlyweightFlyweight (Fliegengewicht)(Fliegengewicht)

• gemeinsame Nutzung großer Mengen leichtgewichtiger Objekte

• Anwendbarkeit– große Mengen von Objekten– viele Gruppen von Objekten können gemeinsam genutzt werden– Großteil des Objektzustandes ist extrinsisch

• Konsequenzen– gemeinsame Nutzung gemeinsame Objektidentität


Bridge Bridge (Br(Brüücke)cke)

• entkoppelt eine Abstraktion von ihrer Implementierung, so dass beide unabhängig verändert werden können

• Konsequenzen– Implementierung kann zur Laufzeit ausgewählt und gewechselt

werden– eine Implementierung kann von mehreren Objekten genutzt werden– übersichtlichere Klassenhierarchien


ProxyProxy

• stellt ein vorgelagertes Stellvertreterobjekt dar• kontrolliert bzw. steuert den Zugriff auf das eigentliche

Objekt

• Anwendbarkeit– Remote-Proxy: Stellvertreter für Objekte in einem anderen Adressraum– Virtuelle Proxy: erzeugt teure Objekte erst auf Verlangen– Schutzproxy: kontrolliert den Zugriff auf das Objekt


FazitFazit

• Entwurfsmuster sind nicht kompliziert• stellen einfache Lösungsstrategien für Entwurfsprobleme

• Strukturmuster zeigen interessante Möglichkeiten für die Komposition von Objekten auf

• aber– Muster sind keine Silberkugel– Muster können den Entwurf auch unnötig aufblähen

nur benötigte Flexibilität mit Mustern begegnen


Vielen Dank für Eure Aufmerksamkeit!


LiteraturLiteratur

• Eilebrecht, K., Starke, G. (2004). „Patterns kompakt: Entwurfsmuster für effektive Software-Entwicklung“ (Spektrum 2004).

• Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1996). „Entwurfsmuster: Elemente wiederverwendbarer objekt-orientierter Software“ (Addison-Wesley 1996).

• Goldfedder, B. (2002). „Entwurfsmuster einsetzen: Einstieg in die Anwendungsentwicklung mit Design Patterns“ (Addison-Wesley 2002).

• Shalloway, A., Trott, J. R. (2003). „Entwurfsmuster verstehen“ (mitP-Verlag 2003).

• Vlissides, J. (1999). „Entwurfsmuster anwenden: Die Fortsetzung des Klassikers der Gang of Four“ (Addison-Wesley 1999).

Structural Patterns - se.uni-hannover.de · Structural Patterns B. Sc. Andreas Meißner Seminar...

Documents

Transcript of Structural Patterns - se.uni-hannover.de · Structural Patterns B. Sc. Andreas Meißner Seminar...