Welche Design Patterns sind in PHP-Frameworks verbreitet?

Question

Accepted Answer

PHP-Frameworks (Laravel, Symfony) basieren auf klassischen **Design Patterns** — wiederverwendbaren Lösungen für häufige Designprobleme. Wenn du sie erkennst, hilfst du dir selbst, zu verstehen, wie Frameworks funktionieren, und du schreibst selbst besser strukturierten Code.

## MVC (Model-View-Controller) — das Architektur-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 Pattern — abstrahiere Datenzugriff

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

Das **Repository** Pattern abstrahiert Datenzugriff hinter einer Schnittstelle — es entkoppelt die Geschäftslogik von der Datenbank und hilft beim Testen.

## Factory — Objekterstellung kapseln

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

## Andere verbreitete Patterns in 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 zeigt besonders diese: **Facades** (statische Proxy für Services), **Active Record** (Eloquent-Modelle), **Observer** (Events/Model Observer), **Strategy** (austauschbare Treiber für Cache, Queue, Auth).

## Warum es wichtig ist

Design Patterns sind wichtiges Wissen für PHP-Entwickler, weil die großen Frameworks (Laravel, Symfony) vollständig auf ihnen aufgebaut sind — Design Patterns zu verstehen ist daher unerlässlich, um sowohl zu *begreifen, wie diese Frameworks funktionieren*, als auch um selbst gut strukturierten Code zu schreiben.

Wenn du **MVC** erkennst (das Architektur-Fundament fast jedes PHP-Web-Frameworks), **Dependency Injection / IoC Container** (wie Frameworks Abhängigkeiten verdrahten für Entkopplung und Testbarkeit), das **Repository Pattern** (Datenzugriff abstrahieren für testbare, austauschbare Persistierung) und Framework-spezifische Patterns wie Laravels **Facades** (statische Proxy für Services), **Active Record** (Eloquent-Modelle) und **Observer** (Events), demystifizierst du die "Magie" dieser Frameworks und kannst sie effektiv nutzen und erweitern.

Über das Verständnis von Frameworks hinaus gibt dir die Kenntnis verbreiteter Patterns ein gemeinsames Vokabular für Design-Diskussionen, bewährte Lösungen für wiederkehrende Probleme und die Fähigkeit, wartbaren und flexiblen Code zu entwerfen.

Da professionelle PHP-Entwicklung fast immer innerhalb von Pattern-lastigen Frameworks stattfindet und gutes Anwendungsdesign auf angemessener Pattern-Nutzung beruht, ist Verständnis für verbreitete Design Patterns — was sie lösen und wo sie im PHP-Ökosystem auftauchen — wertvolles Senior-Level-Wissen, das Entwickler, die ihre Werkzeuge tiefgreifend verstehen und gut strukturierte Anwendungen bauen können, von denen unterscheidet, die Frameworks oberflächlich nutzen. (Der Vorbehalt wie immer: Patterns sind Werkzeuge für echte Probleme, nicht Ziele — sie anzuwenden, wo sie nicht passen, erzeugt unnötige Komplexität.)