Objektorientierte Entwurfsmuster - Architektur und Entwurfsmuster der Softwaretechnik - page 113

public void write (byte[] b, int off, int len) throws IOException
{
int i;
for (i = off; i<= off+len; i++)
{
buffer[counter] = b[i]; // in Puffer legen
counter ++;
if (counter == 1024) // falls Puffer voll
{
out.write (buffer); // Puffer in Stream schreiben
counter = 0;
}
}
}
}

Der Dekorierer leitet also alle Methodenaufrufe an das aggregierte Objekt vom Typ
OutputStream weiter, nachdem er die Pufferung durchgeführt hat.

Sowohl die Klasse PipedOutputStream als auch die Klasse FileOutputStream
sind von der Klasse OutputStream abgeleitet. Ein Objekt einer abgeleiteten Klasse
kann nach dem liskovschen Substitutionsprinzip an die Stelle eines vom Dekorierer
aggregierten Objekts treten, wenn die Verträge bei der Ableitung eingehalten werden.
Es wird damit dekoriert, in diesem Beispiel also gepuffert.

4.5.5.2 Anwendungsbeispiel 2: grafische Komponenten

Im folgenden Beispiel dekoriert der Dekorierer im wahrsten Sinne des Wortes, nämlich
er verziert grafische Komponenten mit einem Rahmen:

Komponente
{abstract}

Textfeld Schaltfläche Rahmen

Bild 4-16 Weiteres Beispiel für den Dekorierer

Auf lauffähigen Code wird an dieser Stelle verzichtet.

Ein ganz ähnliches Beispiel folgt in Kapitel 4.7.5 beim Kompositum-Muster (vgl. Bild
4-24). Der Unterschied zwischen diesen beiden Beispielen liegt aber in der Funktiona-
lität: Durch die Dekoriererklasse Rahmen kann jede grafische Komponente mit einem
Rahmen verziert werden. Diese Klasse ist aber nicht in der Lage, mehrere grafische
Komponenten zu einer Gruppe zusammenzufassen und diese Gruppe dann zu um-
rahmen. Das Zusammenfassen leistet beispielsweise die Klasse Fenster in Bild 4-24
beim Kompositum-Muster. Da die Klasse Fenster wiederum eine grafische Kompo-