SOLID-Prinzipien in PHP: Fortgeschrittene Anwendung und praktische Beispiele

Einleitung: Warum SOLID nicht nur ein Dogma, sondern ein Werkzeug ist

Die meisten Entwickler wissen, dass SOLID die fünf Prinzipien der objektorientierten Programmierung sind: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation und Dependency Inversion. In der Praxis beschränkt sich das Verständnis jedoch oft auf das mechanische Befolgen von Regeln. In diesem Artikel gehen wir weiter: Wir analysieren fortgeschrittene Anwendungsszenarien von SOLID in PHP, betrachten Antipatterns, die gegen die Prinzipien verstoßen, und zeigen, wie Refactoring unter Berücksichtigung von SOLID den Code flexibel und testbar macht.

Das Material richtet sich an Entwickler auf Middle+- und Senior-Niveau, die bereits in PHP schreiben und die Architektur ihrer Projekte verbessern möchten.

1. Prinzip der einzigen Verantwortung (SRP): Wenn eine Klasse „zu viel weiß“

Die klassische Formulierung: „Eine Klasse sollte nur einen Grund für eine Änderung haben.“ Auf fortgeschrittenem Niveau ist es wichtig zu verstehen, dass „Grund für eine Änderung“ eine Geschäftsanforderung ist. Wenn sich Ihre Klasse aufgrund von Änderungen der Validierungsregeln, des Ausgabeformats und der Speicherlogik ändert, liegt ein Verstoß gegen SRP vor.

Beispiel für einen Verstoß (God Object)

class OrderProcessor {    public function process(array $data): void {        // 1. Datenvalidierung        if (empty($data['user_id']) || empty($data['items'])) {            throw new InvalidArgumentException('Invalid order data');        }                // 2. Kostenberechnung        $total = 0;        foreach ($data['items'] as $item) {            $total += $item['price'] * $item['quantity'];        }                // 3. Speicherung in der DB        $sql = "INSERT INTO orders (user_id, total, status) VALUES (?, ?, 'pending')";        // ... Ausführung der Abfrage                // 4. E-Mail-Versand        mail($data['user_email'], 'Order confirmation', "Total: $total");    }}

Refactoring mit SRP

Wir teilen in drei Klassen mit klaren Verantwortungsbereichen auf:

class OrderValidator {    public function validate(array $data): void {        if (empty($data['user_id']) || empty($data['items'])) {            throw new InvalidArgumentException('Invalid order data');        }    }}

class OrderCalculator {    public function calculateTotal(array $items): float {        return array_reduce($items, function ($carry, $item) {            return $carry + $item['price'] * $item['quantity'];        }, 0.0);    }}

class OrderRepository {    public function save(int $userId, float $total, string $status = 'pending'): int {        // Logik zur Speicherung in der DB        return 42; // Bestell-ID    }}

class OrderProcessor {    public function __construct(        private OrderValidator $validator,        private OrderCalculator $calculator,        private OrderRepository $repository,        private Mailer $mailer    ) {}        public function process(array $data): void {        $this->validator->validate($data);        $total = $this->calculator->calculateTotal($data['items']);        $orderId = $this->repository->save($data['user_id'], $total);        $this->mailer->send($data['user_email'], 'Bestellung #' . $orderId);    }}

2. Prinzip der Offenheit/Geschlossenheit (OCP): Erweiterung ohne Modifikation

Der Kern von OCP: Klassen sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. In der Praxis bedeutet dies die Verwendung von Polymorphismus und Abstraktionen anstelle von bedingten Konstrukten.

Verstoß gegen OCP: switch-case für jeden neuen Typ

class PaymentProcessor {    public function pay(string $type, float $amount): void {        switch ($type) {            case 'credit_card':                // Kartenverarbeitung                break;            case 'paypal':                // PayPal-Verarbeitung                break;            // Beim Hinzufügen eines neuen Typs ändern wir die Klasse!        }    }}