Decorator

Der Decorator (auch Dekorierer) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung, das zur Kategorie der Strukturmuster (engl. structural patterns) gehört. Das Muster ist eine flexible Alternative zur Unterklassenbildung, um eine Klasse um zusätzliche Funktionalitäten zu erweitern.[1] Es ist ein Entwurfsmuster der sogenannten GoF-Muster.

## Inhaltsverzeichnis

* 1 Verwendung
* 1.1 Akteure
* 1.2 Vor- und Nachteile
* 2 Beispiele
* 2.1 C++
* 2.2 Die Stream-Klassen der Java-Bibliothek
* 2.3 Erweitern von GUI-Komponenten
* 2.4 Erweitern der Funktionalität von GUI-Komponenten
* 2.5 Ein Beispiel in C#
* 3 Verwandte Muster
* 4 Einzelnachweise

## Verwendung

[Bearbeiten | Quelltext bearbeiten]

Die Instanz eines Dekorierers wird vor die zu dekorierende Klasse geschaltet. Der Dekorierer hat die gleiche Schnittstelle wie die zu dekorierende Klasse. Aufrufe an den Dekorierer werden dann verändert oder unverändert weitergeleitet (Delegation), oder sie werden komplett in Eigenregie verarbeitet. Der Dekorierer ist dabei „unsichtbar“, da der Aufrufende gar nicht mitbekommt, dass ein Dekorierer vorgeschaltet ist.

Entwurfsmuster Dekorierer in UML-Notation

In einer alternativen Variante kann der Dekorierer als eine Strategie eingebunden und explizit aufgerufen werden.

### Akteure

[Bearbeiten | Quelltext bearbeiten]

Die abstrakte Komponente definiert die öffentliche Schnittstelle für die zu dekorierenden Objekte. Die konkrete Komponente definiert Objekte, die dekoriert werden können.

Der abstrakte Dekorierer hält eine Referenz auf die abstrakte Komponente und bietet dieselbe Schnittstelle wie die abstrakte Komponente. Der konkrete Dekorierer definiert und implementiert eine oder mehrere spezielle Dekorationen.

### Vor- und Nachteile

[Bearbeiten | Quelltext bearbeiten]

Die Vorteile bestehen darin, dass mehrere Dekorierer hintereinandergeschaltet werden können; die Dekorierer können zur Laufzeit und sogar nach der Instanziierung ausgetauscht werden. Die zu dekorierende Klasse ist nicht unbedingt festgelegt (wohl aber deren Schnittstelle). Zudem können lange und unübersichtliche Vererbungshierarchien vermieden werden.

Das Muster hat eine Gefahr: Da eine dekorierte Komponente nicht identisch mit der Komponente selbst ist (als Objekt), muss man beim Testen auf Objekt-Identität vorsichtig sein. (Ein Vergleich kann falsch ausgehen, obwohl dieselbe Komponente gemeint ist.) Zudem müssen bei der Verwendung von dekorierten Komponenten die Nachrichten vom Dekorierer an das dekorierte Objekt weitergeleitet werden.

## Beispiele

[Bearbeiten | Quelltext bearbeiten]

### C++

[Bearbeiten | Quelltext bearbeiten]

Diese C++14 Implementierung basiert auf der vor C++98 Implementierung im Buch Entwurfsmuster.

#include <iostream>
#include <memory>

// definiert die Schnittstelle für Objekte, denen Verantwortlichkeiten dynamisch hinzugefügt werden können.
class VisuelleKomponente { // Komponente
public:
virtual void zeichne() = 0;
virtual ~VisuelleKomponente() = default;

// definiert ein Objekt, das um zusätzliche Funktionalität erweitert werden kann.
class TextAnzeige : public VisuelleKomponente { // KonkreteKomponente
public:
virtual void zeichne() {
std::cout << "TextAnzeige::zeichne ";

// verwaltet eine Referenz auf ein Komponentenobjekt und definiert eine Schnittstelle, die der Schnittstelle von Komponente entspricht.
class Dekorierer : public VisuelleKomponente {
public:
Dekorierer() : komponente(nullptr) {}
Dekorierer(VisuelleKomponente* komponente_) : komponente(komponente_) {}
Dekorierer(const Dekorierer&) = delete; // Dreierregel
Dekorierer& operator=(const Dekorierer&) = delete;
virtual void zeichne() {
komponente->zeichne();

protected:
VisuelleKomponente* komponente;

// fügt der Komponente Funktionalität hinzu.
class RahmenDekorierer : public Dekorierer { // KonkreterDekorierer
public:
RahmenDekorierer(std::shared_ptr<VisuelleKomponente> komponente_,
int breite_) : breite(breite_) {
komponente = komponente_.get();

virtual void zeichne() {
Dekorierer::zeichne();
zeichneRahmen(breite);

private:
void zeichneRahmen(int breite_) {
std::cout << "RahmenDekorierer::zeichneRahmen breite_=" << breite_ << ' ';

int breite;

class Fenster {
public:
void setInhalt(std::shared_ptr<VisuelleKomponente> contents_) {
contents = contents_.get();

void zeichne() {
contents->zeichne();
std::cout << '\n';

private:
VisuelleKomponente* contents;

int main() {
// Die Smart pointers verhindern Memory Leaks.
std::unique_ptr<Fenster> fenster = std::make_unique<Fenster>();

std::shared_ptr<TextAnzeige> textAnzeige = std::make_shared<TextAnzeige>();
fenster->setInhalt(textAnzeige);
fenster->zeichne();

std::shared_ptr<RahmenDekorierer> bd1 = std::make_shared<RahmenDekorierer>
(textAnzeige, 1);
fenster->setInhalt(bd1);
fenster->zeichne();

std::shared_ptr<RahmenDekorierer> bd2 = std::make_shared<RahmenDekorierer>
(textAnzeige, 2);
std::shared_ptr<RahmenDekorierer> bd3 = std::make_shared<RahmenDekorierer>
(bd2, 1);
fenster->setInhalt(bd3);
fenster->zeichne();

Die Programmausgabe ist:

TextAnzeige::zeichne
TextAnzeige::zeichne RahmenDekorierer::zeichneRahmen breite_=1
TextAnzeige::zeichne RahmenDekorierer::zeichneRahmen breite_=2 RahmenDekorierer::zeichneRahmen breite_=1

### Die Stream-Klassen der Java-Bibliothek

[Bearbeiten | Quelltext bearbeiten]

Eine Implementierung des Decorator-Musters stellen die Stream-Klassen in der Java-Bibliothek dar. Man dekoriert das konkrete Stream-Objekt mit Objekten, die neue Eigenschaften zu dem Stream hinzufügen und sich weiter dekorieren lassen. Dabei können Decorator-Objekte verwendet werden, die neue Statusinformationen hinzufügen oder solche, die neue Schnittstellen zur Verfügung stellen.

### Erweitern von GUI-Komponenten

[Bearbeiten | Quelltext bearbeiten]

Ein Textfeld soll mit einer Umrahmung „dekoriert“ werden.

Zwischen dem Aufrufer und dem Textfeldobjekt wird das entsprechende Dekoriererobjekt eingefügt. Das Dekoriererobjekt erzeugt die Umrahmung und übergibt den Kontrollfluss an das Textfeld. Da der Dekorierer dieselbe Schnittstelle hat, ändert sich aus der Sicht des Aufrufers nichts.

### Erweitern der Funktionalität von GUI-Komponenten

[Bearbeiten | Quelltext bearbeiten]

Jede Komponente stellt sich ab dem Ursprungspunkt (0, 0) dar; dies ist die eigentliche, zu dekorierende Klasse. Ein vorgeschalteter Dekorierer kann die Position verschieben, indem Darstellungs- und Mauskoordinaten-Aufrufe verändert werden.

Eine Spezialisierung davon ist ein Dekorierer, der zusätzlich eine feste Größe definiert, außerhalb derer nichts dargestellt werden kann. Eine weitere Spezialisierung erweitert den Darstellungsaufruf um einen darumliegenden Rahmen.

Ein zusätzlicher Dekorierer, der den ersten Dekorierer nochmals dekoriert, kann die Komponente unsichtbar werden lassen oder abschalten, indem Darstellungs- und Mausabfrage-Methoden wahlweise abgeblockt werden.

An diesem Beispiel sieht man auch, dass sich Vererbung und Delegation nicht ausschließen.

### Ein Beispiel in C#

[Bearbeiten | Quelltext bearbeiten]

In einem Abenteuerspiel gibt es Spielfiguren. Jede davon kann Drohungen ausstoßen. Eine konkrete Spielfigur ist beispielsweise ein Monster. Spielfiguren können sich zur Laufzeit Schnupfen und Husten einfangen – dann geht ihren Drohungen ein Schniefen bzw. Husten voraus.

Das folgende Programmbeispiel zeigt, wie das Dekorierer-Muster benutzt wird, um ein Monster zu verschnupfen und zu verhusten.

Wichtig dabei ist zu verstehen, dass nicht die Unterklassen VerschnupftesMonster, VerhustetesMonster, VerschnupftesVerhustetesMonster und VerhustetesVerschnupftesMonster gebildet werden. Dieser Ansatz würde bei Hinzunahme weiterer Attribute wie „wahnsinnig“ und „feuerspuckend“ zu einer exponentiellen Zunahme der Unterklassen führen – ganz abgesehen von unerträglichen Klassennamen wie VerhustetesVerschnupftesWahnsinnigesFeuerspuckendesMonster. Es werden nur die (Reihenfolgen von) Dekorationen erzeugt, die tatsächlich benötigt werden.

Man sieht zudem, dass der Client-Code von den Dekorierern nichts weiß, nachdem die dekorierten Objekte erzeugt wurden. Aus Sicht des Client-Codes lautet der Aufruf zum Drohen immer Spielfigur.Drohe().

using System;

namespace DekoratorMuster

public abstract class Spielfigur

public abstract void Drohe();

public class Monster : Spielfigur

public override void Drohe()

Console.WriteLine("Grrrrrrrr.");

public abstract class Dekorierer : Spielfigur

private Spielfigur meineFigur;

public Dekorierer(Spielfigur s)

meineFigur = s;

public override void Drohe()

meineFigur.Drohe();

public class HustenDekorierer : Dekorierer

public HustenDekorierer(Spielfigur s)
: base(s)
{ }

public override void Drohe()

Console.Write("Hust, hust. ");
base.Drohe();

public class SchnupfenDekorierer : Dekorierer

public SchnupfenDekorierer(Spielfigur s)
: base(s)
{ }

public override void Drohe()

Console.Write("Schniff. ");
base.Drohe();

public class ClientCode

public static void Main()

Spielfigur meinMonster = new Monster();
meinMonster.Drohe();

Spielfigur meinVerhustetesMonster = new HustenDekorierer(meinMonster);
meinVerhustetesMonster.Drohe();

Spielfigur meinVerschnupftesMonster = new SchnupfenDekorierer(meinMonster);
meinVerschnupftesMonster.Drohe();

Spielfigur meinVerschnupftesVerhustetesMonster = new SchnupfenDekorierer(new HustenDekorierer(meinMonster));
meinVerschnupftesVerhustetesMonster.Drohe();

Spielfigur meinVerhustetesVerschnupftesMonster = new HustenDekorierer(new SchnupfenDekorierer(meinMonster));
meinVerhustetesVerschnupftesMonster.Drohe();

Die Ausgabe dieses Programms ist:

Grrrrrrrrr.
Hust, hust. Grrrrrrrrrr.
Schniff. Grrrrrrrrrr.
Schniff. Hust, hust. Grrrrrrrrrr.
Hust, hust. Schniff. Grrrrrrrrrr.

Ähnlich lassen sich Beispiele in C++ und anderen objektorientierten Programmiersprachen erstellen.

## Verwandte Muster

[Bearbeiten | Quelltext bearbeiten]

Im Vergleich zum Dekorierer, welcher die tatsächlich zu verwendende Klasse selbst wählt, muss bei dem Strategie-Muster die aufrufende Instanz explizit wissen, welche Varianten zur Verfügung stehen und welche daraus verwendet werden soll.

Ähnlich dem Dekorierer ist zudem noch das Kompositum-Entwurfsmuster.

## Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]

1. ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster. 5. Auflage. Addison-Wesley, 1996, ISBN 3-8273-1862-9, S. 199.

V – D

Entwurfsmuster

Erzeugungsmuster |

Abstrakte Fabrik | Erbauer | Fabrikmethode | Prototyp | Singleton | Multiton | Objektpool

|

Strukturmuster |

Adapter | Brücke | Decorator | Fassade | Fliegengewicht | Kompositum | Stellvertreter

Verhaltensmuster |

Beobachter | Besucher | Interpreter | Iterator | Kommando | Memento | Schablonenmethode | Strategie | Vermittler | Zustand | Zuständigkeitskette | Interceptor | Nullobjekt | Protokollstapel

Muster für objekt-
relationale Abbildung |

Datentransferobjekt | Table Data Gateway | Row Data Gateway | Active Record | Unit of Work | Identity Map | Lazy Loading | Identity Field | Dependent Mapping | Embedded Value | Serialized LOB | Inheritance Mapper | Metadata Mapping | Query Object | Command-Query-Responsibility-Segregation

Nachrichten-
übermittlungsmuster |

Message | Command Message | Document Message | Event Message | Request-Reply | Return Address | Correlation Identifier | Message Sequence | Message Expiration | Format Indicator | Message Channel | Point-to-Point Channel | Publisher-Subscriber Channel | Datatype Channel | Invalid Message Channel | Dead Letter Channel | Guaranteed Delivery | Channel Adapter | Messaging Bridge | Message Bus | Pipes-and-Filters | Message Router | Content-based Router | Message Filter | Dynamic Router | Recipient List | Splitter | Aggregator | Resequencer | Composed Message Processor | Scatter-Gather | Routing Slip | Process Manager | Message Broker | Message Translator | Envelope Wrapper | Content Enricher | Content Filter | Claim Check | Normalizer | Canonical Data Model | Message Endpoint | Messaging Gateway | Messaging Mapper | Transactional Client | Polling Consumer | Event-driven Consumer | Competing Consumers | Message Dispatcher | Selective Consumer | Durable Subscriber | Idempotent Receiver | Service Activator | Control Bus | Detour | Wire Tap | Message History | Message Store | Smart Proxy | Test Message | Channel Purger

andere |

Application Controller | Business Delegate | Data Access Object | Dependency Injection | Extension Interface | Fluent Interface | Inversion of Control (IoC) | Lock | Model View Controller (MVC) | Model View Presenter (MVP) | Model View Update (MVU) | Model View ViewModel (MVVM) | Page Controller | Registry | Remote Facade | Repository | Service Locator | Session State | Table Module | Template View | Threadpool | Transaction Script | Transform View | Two-Step View | Value Object

Siehe auch:  Analysemuster | Architekturmuster | Integrationsmuster | SOA-Muster