Hva er Decorator-mønsteret?

Question

Accepted Answer

**Decorator**-mønsteret legger dynamisk til **oppførsel eller ansvar** til objekter ved å pakke dem inn — uten å endre den originale klassen. Det gir et fleksibelt alternativ til subklassing for utvidelse av funksjonalitet, og lar deg komponere oppførsel.

## Hva Decorator-mønsteret gjø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
```

## Eksempel

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

## Fordeler og bruksområder

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

## Hvorfor det er viktig

Å forstå Decorator-mønsteret er verdifullt fordi det er et **nyttig strukturelt mønster** for fleksibel utvidelse av oppførsel, så det er praktisk relevant designkunnskap.

Decorator-mønsteret legger oppførsel til objekter ved å **pakke dem inn** (beholder samme grensesnitt, delegerer til original mens det legger til oppførsel), uten å endre den originale klassen — og gir et fleksibelt alternativ til subklassing.

Å forstå hva det gjør (pakke inn et objekt for å legge til oppførsel, med muligheten til å **stable dekoratorer** for å komponere flere oppførelser) er kjernekunnskap.

Å forstå **fordelene** er nøkkelen: det legger oppførsel til **uten å endre original** (følger open/closed-prinsippet) og unngår **eksplosjonen av subklasser** som ville oppstå fra å lage subklasser for hver kombinasjon av funksjoner, det lar deg **komponere oppførsel fleksibelt på kjøretid** (stable ulike dekoratorer i forskjellige kombinasjoner), og det støtter enkeltansvar (hver dekorator legger til én ting).

Denne komponerbareten — å bygge opp oppførsel ved å stable små, fokuserte dekoratorer — er mønsterets viktigste styrke, langt mer fleksibel enn rigid subklassing.

Å forstå **bruksområdene** — I/O-strømmer (det klassiske eksemplet på å pakke inn strømmer), middleware (pakke inn forespørselsbehandlere — vanlig i nettrammeverkene), UI-komponenter, å legge til tversgående funksjoner (logging, caching, validering) rundt et kjerneobjekt, og Reacts higher-order-komponenter — klargjør dens brede, virkelige brukbarhet.

Decorator-mønsteret vises overalt i virkelige rammeverk og biblioteker.

Siden Decorator-mønsteret er et nyttig strukturelt mønster for fleksibel utvidelse av oppførsel (pakke inn for å legge til oppførsel uten å endre originaler eller forårsake subklasseksplosjoner, komponere oppførsel på kjøretid), og siden det å forstå hva det gjør, dets fordeler, og dets vanlige bruksområder (strømmer, middleware, funksjoner) er praktisk relevant, er å forstå Decorator-mønsteret verdifull, hyppig brukt designkunnskap — et nyttig mønster for fleksibel, komponerbar oppførselsutvidelse, som vises gjennom virkelige rammeverk (strømmer, middleware, HOCs), og viktig designkunnskap for å utvide funksjonalitet rent uten å endre originaler eller lage stive subklasshierarkier.