SOLID-Prinzipien in PHP: Theorie und Praxis von A bis Z

Einleitung: Warum SOLID das Fundament für qualitativ hochwertigen PHP-Code ist

Jeder PHP-Entwickler stößt früher oder später auf die Situation, dass sich ein kleines Projekt in "Spaghetti-Code" verwandelt. Klassen werden überladen, Änderungen in einem Teil des Systems zerstören einen anderen, und das Testen wird zum Albtraum. Genau zur Lösung dieser Probleme formulierte Robert C. Martin (Uncle Bob) die fünf SOLID-Prinzipien. Diese Prinzipien sind keine abstrakte Theorie, sondern praktische Werkzeuge, die helfen, flexiblen, wartbaren und testbaren PHP-Code zu erstellen.

In diesem Artikel analysieren wir jedes SOLID-Prinzip: von der Theorie bis zu realen Beispielen in PHP 8.x. Sie erfahren, wie Sie sie in der täglichen Entwicklung anwenden und welche Antipatterns Sie vermeiden sollten.

1. Single Responsibility Principle (SRP) – Prinzip der einzigen Verantwortung

Theorie

Das Prinzip besagt: Eine Klasse sollte nur einen Grund für eine Änderung haben. Das bedeutet, dass jede Klasse für eine bestimmte Funktionalität oder Geschäftslogik verantwortlich sein sollte.

Antipattern (Verletzung des SRP)

<?phpclass OrderProcessor {    public function process(Order $order): void {        // 1. Validierung der Bestellung        if (empty($order->getItems())) {            throw new \\InvalidArgumentException('Bestellung hat keine Artikel');        }                // 2. Speichern in der DB        $db = new \\PDO('mysql:host=localhost;dbname=shop', 'user', 'pass');        $stmt = $db->prepare('INSERT INTO orders ...');        $stmt->execute([...]);                // 3. E-Mail versenden        mail($order->getCustomerEmail(), 'Bestellung bestätigt', '...');                // 4. Logging        file_put_contents('/var/log/orders.log', 'Bestellung verarbeitet: '.$order->getId());    }}?>

Hier macht die Klasse OrderProcessor zu viel: validiert, arbeitet mit der DB, sendet E-Mails, loggt. Die Verletzung des SRP führt dazu, dass eine Änderung der E-Mail-Logik eine Änderung der Klasse erfordert, die für die Bestellverarbeitung zuständig ist.

Refactoring unter Einhaltung des SRP

<?phpclass OrderValidator {    public function validate(Order $order): void {        if (empty($order->getItems())) {            throw new \\InvalidArgumentException('Bestellung hat keine Artikel');        }    }}

class OrderRepository {    public function save(Order $order): void {        // Logik zum Speichern in der DB    }}

class EmailNotifier {    public function sendOrderConfirmation(Order $order): void {        // Logik zum E-Mail-Versand    }}

class Logger {    public function log(string $message): void {        // Logging    }}

class OrderProcessor {    public function __construct(        private OrderValidator $validator,        private OrderRepository $repository,        private EmailNotifier $notifier,        private Logger $logger    ) {}        public function process(Order $order): void {        $this->validator->validate($order);        $this->repository->save($order);        $this->notifier->sendOrderConfirmation($order);        $this->logger->log('Bestellung verarbeitet: '.$order->getId());    }}?>

Jetzt hat jede Klasse eine einzige Verantwortung. Eine Änderung der E-Mail-Logik beeinträchtigt nicht die Arbeit mit der DB.

2. Open-Closed Principle (OCP) – Prinzip der Offenheit/Geschlossenheit

Theorie

Softwareentitäten sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. Mit anderen Worten: Sie sollten in der Lage sein, neue Funktionalität hinzuzufügen, ohne vorhandenen Code zu ändern.

Antipattern

<?phpclass PaymentProcessor {    public function process(string $type, float $amount): void {        if ($type === 'credit_card') {            // Kreditkartenverarbeitung        } elseif ($type === 'paypal') {            // PayPal-Verarbeitung\