Vad är Decorator-mönstret?

Question

Accepted Answer

**Decorator**-mönstret lägger dynamiskt till **beteende eller ansvar** till objekt genom att linda in dem — utan att ändra den ursprungliga klassen. Det ger ett flexibelt alternativ till subklassificering för att utöka funktionalitet, och låter dig komponera beteenden.

## Vad Decorator-mönstret gör

```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
```

## Exempel

```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
```

## Fördelar och användningsfall

```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
```

## Varför det är viktigt

Att förstå Decorator-mönstret är värdefullt eftersom det är ett **användbart strukturellt mönster** för att flexibelt utöka beteende, så det är praktiskt relevant designkunskap.

Decorator-mönstret lägger till beteende till objekt genom att **linda in dem** (behålla samma gränssnitt, delegera till originalet medan beteende läggs till), utan att ändra den ursprungliga klassen — vilket ger ett flexibelt alternativ till subklassificering.

Att förstå vad det gör (linda in ett objekt för att lägga till beteende, med möjligheten att **stapla decorators** för att komponera flera beteenden) är kärnkunskapen.

Att förstå **fördelarna** är nyckeln: det lägger till beteende **utan att ändra originalet** (enligt principen open/closed) och undviker **explosionen av subklasser** som skulle resultera från att skapa subklasser för varje kombination av funktioner, det låter dig **komponera beteenden flexibelt vid körning** (stapla olika decorators i olika kombinationer), och det stöder Single Responsibility (varje decorator lägger till en sak).

Denna kompositionalitet — att bygga upp beteende genom att stapla små, fokuserade decorators — är mönstrets nyckelstyrka, långt mer flexibel än stel subklassificering.

Att förstå **användningsfallen** — I/O-strömmar (det klassiska exemplet på att linda in strömmar), middleware (linda in request-hanterare — vanligt i webbramverk), UI-komponenter, att lägga till övergripande funktioner (loggning, cachelagring, validering) runt ett kärnöbjekt, och Reacts higher-order components — klargör dess breda verklig-världen-tillämpning.

Decorator-mönstret förekommer genomgående i verkliga ramverk och bibliotek.

Eftersom Decorator-mönstret är ett användbart strukturellt mönster för att flexibelt utöka beteende (linda in för att lägga till beteende utan att ändra original eller få subklassexplosion, komponera beteenden vid körning), och eftersom att förstå vad det gör, dess fördelar och dess vanliga användningsfall (strömmar, middleware, funktioner) är praktiskt relevant, är att förstå Decorator-mönstret värdefullt, allmänt användbar designkunskap — ett användbart mönster för flexibel, komposabel beteendeutökning, förekommande genomgående i verkliga ramverk (strömmar, middleware, HOCs), och viktig designkunskap för att utöka funktionalitet rent utan att ändra original eller skapa stela subklasshierarkier.