Hva er Factory-mønsteret?

Question

Accepted Answer

**Factory**-mønsteret gir en måte å **lage objekter uten å spesifisere deres eksakte klasse** — en metode eller klasse som håndterer objektoppretting, og bestemmer hvilken type som skal instansieres. Det sentraliserer og abstraherer objektoppretting, og kobler fra kode fra konkrete klasser.

## Hva Factory-mønsteret gjør

```text
FACTORY → encapsulate object CREATION (instead of calling constructors directly):
  → a factory method/class decides WHICH class to instantiate and creates it
  → the caller asks the factory for an object (by type/parameter) → gets the right object
    WITHOUT knowing/specifying the concrete class
→ decouples code from CONCRETE classes; centralizes creation logic
```

## Eksempel

```js
// a factory creates the right type based on input
class ShapeFactory {
  static create(type) {
    switch (type) {
      case 'circle': return new Circle();
      case 'square': return new Square();
      default: throw new Error('Unknown shape');
    }
  }
}
const shape = ShapeFactory.create('circle');   // caller doesn't use 'new Circle' directly
// → to add a new shape, change the factory, not all the calling code
```

## Fordeler og varianter

```text
BENEFITS:
  ✓ DECOUPLING → callers depend on an interface/factory, not concrete classes
  ✓ CENTRALIZED creation → creation logic in one place (easier to change/extend)
  ✓ FLEXIBILITY → easy to add new types (change the factory) or swap implementations
VARIATIONS:
  → FACTORY METHOD → a method (often overridden by subclasses) creates objects
  → ABSTRACT FACTORY → creates families of related objects
  → simple factory (as above) is the basic form
```

## Hvorfor det betyr noe

Å forstå Factory-mønsteret er verdifullt fordi det er et **vanlig, nyttig kreatormønster** for å koble fra kode fra objektoppretting, så det er praktisk relevant designkunnskap.

Factory-mønsteret innkapsler objektoppretting — en fabrikk-metode eller klasse bestemmer hvilken klasse som skal instansieres, så kallere ber om et objekt (etter type eller parameter) og får det rette **uten å kjenne til eller spesifisere den konkrete klassen**.

Å forstå dette er verdifullt fordi det adresserer et reelt behov: **koble fra kode fra konkrete klasser** (kallere avhenger av fabrikken/grensesnittet i stedet for spesifikke implementeringer) og **sentralisere opprettelseslogikk** (på ett sted, noe som gjør det lettere å endre og utvide).

Å forstå **fordelene** — frakobling, sentralisert oppretting, og fleksibilitet (lett å legge til nye typer ved å endre fabrikken, eller bytte implementeringer, uten å endre all koden som kaller) — gjør det klart hvorfor mønsteret er nyttig for vedlikeholdbar, fleksibel kode.

Å forstå **variantene** — den enkle fabrikken (en metode som bestemmer hva som skal lages), **factory method** (ofte overstyrt av underklasser), og **abstract factory** (laging av familier av relaterte objekter) — dekker spekteret av fabrikk-tilnærminger.

Factory-mønsteret er vanlig brukt og hyppig diskutert, og vises gjennom virkelige kodebaser og rammeverk der objektoppretting må være fleksibel eller frakoblet.

Fordi Factory-mønsteret er et vanlig, nyttig kreatormønster for å koble fra kode fra objektoppretting og sentralisere opprettelseslogikk (som forbedrer fleksibilitet og vedlikeholdbarhet), og fordi å forstå hva det gjør, dets fordeler og dets varianter er praktisk relevant, er å forstå Factory-mønsteret verdifull, allment anvendelig designkunnskap — et hyppig brukt kreatormønster for frakobling og fleksibilitet i objektoppretting, vanlig i virkelige kodebaser og rammeverk, og viktig designkunnskap for å skrive vedlikeholdbar, fleksibel kode.