Hvilke designmønstre er almindelige i PHP-frameworks?

Question

Accepted Answer

PHP-frameworks (Laravel, Symfony) er bygget på klassiske **designmønstre** — genbrugelige løsninger på almindelige designproblemer. At genkende dem hjælper dig med at forstå, hvordan frameworks fungerer, og skrive bedre struktureret kode selv.

## MVC (Model-View-Controller) — det arkitektoniske fundament

```text
Model      → data + business logic (e.g. Eloquent models)
View       → presentation (templates: Blade, Twig)
Controller → handles requests, coordinates models & views
→ The structural pattern of nearly every PHP web framework.
```

## Dependency Injection / IoC Container

```php
// frameworks use a container to resolve & inject dependencies (decoupling, testability)
$service = $container->get(UserService::class);   // dependencies auto-wired
```

## Repository-mønster — abstraktion af dataadgang

```php
interface UserRepository {
    public function find(int $id): ?User;
}
class EloquentUserRepository implements UserRepository { /* DB-specific impl */ }
// services depend on the INTERFACE → swap data sources, mock in tests
```

**Repository**-mønsteret abstraher dataadgang bag en interface — decoupling af forretningslogik fra databasen og hjælp til testing.

## Factory — indkapsulering af objektoprettelse

```php
class PaymentFactory {
    public static function create(string $type): PaymentGateway {
        return match($type) {
            'stripe' => new StripeGateway(),
            'paypal' => new PayPalGateway(),
        };
    }
}
```

## Andre almindelige mønstre i PHP-frameworks

```text
Singleton  → one shared instance (often via the DI container, e.g. config, DB connection)
Observer   → event/listener systems (Laravel events, model observers)
Strategy   → interchangeable algorithms (e.g. different cache/auth drivers)
Decorator  → wrap to add behavior (middleware-style request/response wrapping)
Facade     → a simple static interface to complex subsystems (Laravel Facades:
             Cache::get(), DB::table() — proxy to container-resolved services)
Adapter    → uniform interface over different implementations (e.g. filesystem drivers)
Active Record → models that wrap DB rows with query/save methods (Eloquent)
```

Laravel især demonstrerer disse: **Facades** (statiske proxier til services), **Active Record** (Eloquent-modeller), **Observer** (events/modelobservatører), **Strategy** (udskiftelige drivere til cache, queue, auth).

## Hvorfor det betyder noget

Designmønstre er vigtig viden for PHP-udviklere, fordi de vigtigste frameworks (Laravel, Symfony) er bygget helt på dem — så at forstå mønstre er væsentligt både for at forstå, *hvordan disse frameworks fungerer*, og for at skrive velstruktureret kode selv.

At genkende **MVC** (det arkitektoniske fundament for næsten ethvert PHP-webframework), **Dependency Injection / IoC-containere** (hvordan frameworks forbinder afhængigheder til decoupling og testbarhed), **Repository-mønsteret** (abstraktion af dataadgang til testbar, udskiftelig persistens), og framework-specifikke mønstre som Laravels **Facades** (statiske proxier til services), **Active Record** (Eloquent-modeller), og **Observer** (events) afmystificerer "magien" i disse frameworks og lader dig bruge og udvide dem effektivt.
/*.ud over at forstå frameworks giver kendskab til almindelige mønstre dig et fælles ordforråd til designdiskussioner, påviste løsninger på tilbagevendende problemer, og evnen til at arkitektur vedligeholdelsesbar, fleksibel kode.

Da professionel PHP-udvikling næsten altid foregår inden for mønstertunge frameworks, og da god applikationsdesign afhænger af passende mønsteri, er det at forstå de almindelige designmønstre — hvad de løser og hvor de vises sig i PHP-økosystemet — værdifuld seniorlevelsviden, der adskiller udviklere, der dybt forstår deres værktøjer og kan bygge velarkitekturerede applikationer fra dem, der bruger frameworks overfladisk. (Som altid: mønstre er værktøjer til rigtige problemer, ikke mål — at anvende dem hvor de ikke passer, tilføjer unødvendig kompleksitet.)