Was ist das Decorator-Pattern?

Question

Accepted Answer

Das **Decorator**-Pattern fügt **Verhalten oder Verantwortlichkeiten** dynamisch zu Objekten hinzu, indem es diese umhüllt — ohne die ursprüngliche Klasse zu modifizieren. Es bietet eine flexible Alternative zu Subclassing für die Erweiterung von Funktionalität und ermöglicht es dir, Verhaltensweisen zusammenzustellen.

## Was das Decorator-Pattern bewirkt

```text
DECORATOR → WRAP an object to add behavior, keeping the same interface:
  → the decorator wraps the original, adds its behavior, and delegates to the original
  → you can STACK decorators (wrap a wrapped object) → compose multiple behaviors
  → adds functionality WITHOUT modifying the original class or using subclassing
→ "wrap to extend" — flexible, composable behavior addition
```

## Beispiel

```js
// base object
let coffee = { cost: () => 5, description: () => 'coffee' };
// decorators wrap and add behavior
function withMilk(c) {
  return { cost: () => c.cost() + 1, description: () => c.description() + ' + milk' };
}
function withSugar(c) {
  return { cost: () => c.cost() + 0.5, description: () => c.description() + ' + sugar' };
}
coffee = withSugar(withMilk(coffee));   // stack decorators
coffee.cost();          // 6.5 — composed behavior
```

## Vorteile und Anwendungen

```text
BENEFITS:
  ✓ Add behavior WITHOUT modifying the original (open/closed) or subclass explosion
  ✓ COMPOSE behaviors flexibly at runtime (stack different decorators in combinations)
  ✓ Single responsibility → each decorator adds one thing
USES → I/O streams (wrapping streams), middleware (wrap request handlers), UI components,
  adding features (logging, caching, validation) around a core object; HOC in React
```

## Warum es wichtig ist

Das Verständnis des Decorator-Patterns ist wertvoll, weil es ein **nützliches Strukturmuster** für flexible Verhaltensorweiterung ist und somit praktisch relevantes Design-Wissen darstellt.

Das Decorator-Pattern fügt Verhalten zu Objekten hinzu, indem es sie **umhüllt** (die gleiche Schnittstelle behält, an das Original delegiert und Verhalten hinzufügt), ohne die ursprüngliche Klasse zu modifizieren — und bietet somit eine flexible Alternative zu Subclassing.

Das Verständnis dessen, was es bewirkt (ein Objekt umhüllen, um Verhalten hinzuzufügen, mit der Möglichkeit, **Decorators zu stapeln**, um mehrere Verhaltensweisen zusammenzustellen), ist das Kernwissen.

Das Verständnis der **Vorteile** ist entscheidend: Es fügt Verhalten **ohne Modifizierung des Originals** hinzu (folgt dem Open/Closed-Prinzip) und vermeidet die **Subclass-Explosion**, die durch das Erstellen von Subclassen für jede Kombination von Features entstehen würde, es ermöglicht **flexible Verhaltenskomposition zur Laufzeit** (Stapeln verschiedener Decorators in verschiedenen Kombinationen), und es unterstützt Single Responsibility (jeder Decorator fügt eine Sache hinzu).

Diese Komposierbarkeit — Verhalten durch Stapeln kleiner, fokussierter Decorators aufbauen — ist die Kernstärke des Patterns, weit flexibler als starres Subclassing.

Das Verständnis der **Anwendungen** — I/O-Streams (das klassische Beispiel für das Umhüllen von Streams), Middleware (Umhüllen von Request-Handlern — häufig in Web-Frameworks), UI-Komponenten, das Hinzufügen querschnittlicher Features (Logging, Caching, Validierung) um ein Core-Objekt, und Reacts Higher-Order Components — verdeutlicht seine breite Anwendbarkeit in der Praxis.

Das Decorator-Pattern erscheint überall in echten Frameworks und Bibliotheken.

Da das Decorator-Pattern ein nützliches Strukturmuster für flexible Verhaltensorweiterung ist (Umhüllen zum Hinzufügen von Verhalten ohne Modifizierung von Originalen oder Subclass-Explosion, Komposition von Verhaltensweisen zur Laufzeit), und da das Verständnis dessen, was es bewirkt, seiner Vorteile und seiner häufigen Anwendungen (Streams, Middleware, Features) praktisch relevant ist, ist das Verständnis des Decorator-Patterns wertvoll und weit anwendbares Design-Wissen — ein nützliches Pattern für flexible, komposierbare Verhaltensorweiterung, das überall in echten Frameworks (Streams, Middleware, HOCs) erscheint und wichtiges Design-Wissen für saubere Funktionserweiterung ohne Modifizierung von Originalen oder das Erstellen von starren Subclass-Hierarchien darstellt.