SOLID-Prinzipien in PHP: Theorie und Praxis für sauberen Code

SOLID-Prinzipien in PHP: Theorie und Praxis

SOLID ist ein Akronym für fünf grundlegende Prinzipien der objektorientierten Programmierung, formuliert von Robert C. Martin (Uncle Bob). Diese Prinzipien helfen dabei, flexiblen, wartbaren und skalierbaren Code zu erstellen. In diesem Artikel werden wir jedes Prinzip anhand von PHP-Beispielen erläutern und zeigen, wie man sie in realen Projekten anwendet.

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

Kernaussage: Jede Klasse sollte nur einen einzigen Grund für Änderungen haben. Mit anderen Worten, eine Klasse sollte nur für eine einzige Aufgabe verantwortlich sein.

Verletzung des SRP:

class Order {    public function calculateTotal() { /* ... */ }    public function saveToDatabase() { /* ... */ }    public function sendEmailNotification() { /* ... */ }}

Hier ist die Klasse Order sowohl für die Berechnung, als auch für das Speichern und das Senden von Benachrichtigungen verantwortlich. Dies verletzt das SRP.

Lösung:

class Order {    public function calculateTotal() { /* ... */ }}

class OrderRepository {    public function save(Order $order) { /* ... */ }}

class EmailNotificationService {    public function sendOrderConfirmation(Order $order) { /* ... */ }}

Jetzt hat jede Klasse eine klare, einzige Verantwortung, was das Testen und die Modifikation vereinfacht.

2. Open-Closed Principle (OCP) — Prinzip der Offenheit/Abgeschlossenheit

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

Verletzung des OCP:

class PaymentProcessor {    public function process($type) {        if ($type == 'credit_card') {            // Kreditkartenabwicklung        } elseif ($type == 'paypal') {            // PayPal-Abwicklung        }    }}

Um eine neue Zahlungsmethode hinzuzufügen, müsste die Klasse PaymentProcessor geändert werden.

Lösung unter Verwendung von Interfaces:

interface PaymentMethod {    public function process();}

class CreditCardPayment implements PaymentMethod {    public function process() { /* ... */ }}

class PayPalPayment implements PaymentMethod {    public function process() { /* ... */ }}

class PaymentProcessor {    public function process(PaymentMethod $method) {        $method->process();    }}

Jetzt reicht es aus, eine neue Klasse zu erstellen, die das Interface PaymentMethod implementiert, um eine neue Zahlungsmethode hinzuzufügen, ohne den vorhandenen Code zu ändern.

3. Liskov Substitution Principle (LSP) — Prinzip der Substitution (Barbara Liskov)

Kernaussage: Objekte von Unterklassen sollten durch Objekte der Basisklasse ersetzbar sein, ohne die Korrektheit des Programms zu beeinträchtigen. Eine Unterklasse sollte das vom Basisklasse erwartete Verhalten nicht ändern.

Verletzung des LSP:

class Rectangle {    protected $width;    protected $height;

    public function setWidth($w) { $this->width = $w; }    public function setHeight($h) { $this->height = $h; }    public function getArea() { return $this->width * $this->height; }}

class Square extends Rectangle {    public function setWidth($w) {        $this->width = $w;        $this->height = $w; // Prinzipverletzung    }    public function setHeight($h) {        $this->height = $h;        $this->width = $h; // Prinzipverletzung    }}

Wenn der Client-Code erwartet, dass eine Änderung der Breite keinen Einfluss auf die Höhe hat, dann verletzt Square diese Erwartung.

Lösung: Vermeiden Sie Vererbung, wenn die Unterklasse nicht vollständig dem Verhalten der Elternklasse entspricht. Verwenden Sie stattdessen Komposition oder separate Klassen:

interface Shape