User registered!
"; } else { echo "Email already exists.
"; } } else { echo "Invalid email.
"; } } ?> ``` ### Der gute Weg: Separation of Concerns (Trennung der Belange) Wir refaktorisieren dies, indem wir die Datenbankinteraktion (Repository), die Geschäfts-/Validierungsregeln (Controller) und die visuelle Präsentation (Blade/Template) voneinander trennen. ```php // app/Repositories/UserRepository.php declare(strict_types=1); namespace App\Repositories; use PDO; class UserRepository { private PDO $pdo; public function __construct(PDO $pdo) { $this->pdo = $pdo; } public function findByEmail(string $email): ?array { $stmt = $this->pdo->prepare("SELECT * FROM users WHERE email = :email"); $stmt->execute(['email' => $email]); return $stmt->fetch() ?: null; } public function create(string $email): bool { $stmt = $this->pdo->prepare("INSERT INTO users (email) VALUES (:email)"); return $stmt->execute(['email' => $email]); } } ``` ```php // app/Http/Controllers/RegisterController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Repositories\UserRepository; use InvalidArgumentException; class RegisterController { private UserRepository $userRepository; public function __construct(UserRepository $userRepository) { $this->userRepository = $userRepository; } public function register(array $data): string { $email = $data['email'] ?? ''; if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { throw new InvalidArgumentException("Invalid email format."); } if ($this->userRepository->findByEmail($email) !== null) { return "Email already exists."; } $this->userRepository->create($email); return "User registered!"; } } ``` --- ## Das God Object Ein **God Object** ist eine monolithische Klasse, die zu viel weiß oder zu viel tut. Sie konzentriert die gesamte Intelligenz der Anwendung in sich und verletzt damit das **Single-Responsibility-Prinzip (SRP)**. Andere Klassen im System werden zu reinen Datenhaltern (anämischen Modellen), die von dieser riesigen Klasse gesteuert werden. ### Der schlechte Weg: Ein monolithischer OrderManager Hier wickelt eine einzige Klasse die Verbindung zum Payment-Gateway, das Speichern in der Datenbank, den E-Mail-Versand, Rabattberechnungen und die PDF-Generierung ab. ```php // app/Services/OrderManager.php declare(strict_types=1); namespace App\Services; class OrderManager { public function processOrder(array $orderData): void { // 1. Calculate discount $total = $orderData['price']; if ($orderData['coupon'] === 'SUMMER') { $total *= 0.9; } // 2. Save order to database $db = new \PDO("mysql:host=localhost;dbname=shop", "root", ""); $stmt = $db->prepare("INSERT INTO orders (total, user_id) VALUES (?, ?)"); $stmt->execute([$total, $orderData['user_id']]); // 3. Process payment via Stripe $stripe = new \Stripe\StripeClient('sk_test_key'); $stripe->charges->create([ 'amount' => (int)($total * 100), 'currency' => 'usd', 'source' => $orderData['token'], ]); // 4. Generate PDF invoice $pdf = new \FPDF(); $pdf->AddPage(); $pdf->Write(10, "Invoice total: " . $total); $pdf->Output('F', "/invoices/order.pdf"); // 5. Send email notification mail($orderData['email'], "Order Success", "Your order total is " . $total); } } ``` ### Der gute Weg: Entkoppelte Services Wir refaktorisieren dies, indem wir jede Domänenaufgabe an eine dedizierte Komponente delegieren und die Manager-Klasse als leichtgewichtigen Koordinator beibehalten. ```php // app/Services/OrderService.php declare(strict_types=1); namespace App\Services; use App\Repositories\OrderRepository; use App\Services\Payment\PaymentGatewayInterface; use App\Services\Notification\NotificationInterface; use App\Services\Invoice\InvoiceGeneratorInterface; class OrderService { private OrderRepository $repository; private DiscountCalculator $discountCalculator; private PaymentGatewayInterface $paymentGateway; private InvoiceGeneratorInterface $invoiceGenerator; private NotificationInterface $notifier; public function __construct( OrderRepository $repository, DiscountCalculator $discountCalculator, PaymentGatewayInterface $paymentGateway, InvoiceGeneratorInterface $invoiceGenerator, NotificationInterface $notifier ) { $this->repository = $repository; $this->discountCalculator = $discountCalculator; $this->paymentGateway = $paymentGateway; $this->invoiceGenerator = $invoiceGenerator; $this->notifier = $notifier; } public function checkout(array $orderData): void { $total = $this->discountCalculator->calculate($orderData['price'], $orderData['coupon']); $order = $this->repository->save($total, $orderData['user_id']); $this->paymentGateway->charge($total, $orderData['token']); $invoicePath = $this->invoiceGenerator->generate($order); $this->notifier->sendSuccessNotification($orderData['email'], $total, $invoicePath); } } ``` --- ## Der Golden Hammer Der **Golden Hammer** ist die Annahme, dass eine bevorzugte Technologie oder ein bestimmtes Entwurfsmuster universell anwendbar ist: *„Wenn alles, was Sie haben, ein Hammer ist, sieht alles aus wie ein Nagel.“* In PHP passiert dies oft, wenn Entwickler versuchen, komplexe Struktur- oder Verhaltensmuster (z. B. State oder Visitor) für einfache Aufgaben zu verwenden, was zu einer unnötigen Explosion von Klassen führt, oder wenn sie eine Datenbank-Engine (wie Elasticsearch oder Redis) für Aufgaben nutzen, die problemlos direkt in SQL erledigt werden könnten. ### Der schlechte Weg: Erzwingen des State-Patterns für eine einfache Altersprüfung Ein Entwickler möchte prüfen, ob ein Benutzer Alkohol kaufen darf. Anstelle einer einfachen Bedingung baut er eine komplette State-Pattern-Maschinerie mit mehreren Interfaces und konkreten Klassen auf. ```php // app/Validation/AgeValidator.php declare(strict_types=1); namespace App\Validation; interface AgeStateInterface { public function canPurchaseAlcohol(): bool; } class UnderageState implements AgeStateInterface { public function canPurchaseAlcohol(): bool { return false; } } class AdultState implements AgeStateInterface { public function canPurchaseAlcohol(): bool { return true; } } class AgeValidator { private AgeStateInterface $state; public function __construct(int $age) { $this->state = $age >= 18 ? new AdultState() : new UnderageState(); } public function check(): bool { return $this->state->canPurchaseAlcohol(); } } ``` ### Der gute Weg: Keep It Simple (KISS) Entwurfsmuster erhöhen die Komplexität und die kognitive Belastung. Wenn die Geschäftslogik einfach ist, schreiben Sie sie einfach. ```php // app/Validation/AgeValidator.php declare(strict_types=1); namespace App\Validation; class AgeValidator { private const ALCOHOL_MINIMUM_AGE = 18; public static function canPurchaseAlcohol(int $age): bool { return $age >= self::ALCOHOL_MINIMUM_AGE; } } ``` > [!NOTE] > **Nutzen Sie Muster, wenn die Komplexität es rechtfertigt**: Entwurfsmuster wurden entwickelt, um sich ändernde Anforderungen und hohe Komplexität zu bewältigen. Wenn Ihre Statuslogik nur eine einfache Bedingung enthält, die sich nie ändern wird, ist ein Entwurfsmuster eine Form des Over-Engineerings. --- ## Vorzeitige Optimierung **Vorzeitige Optimierung (Premature Optimization)** bezeichnet das Optimieren von Code hinsichtlich der Performance, bevor man konkrete Beweise (mithilfe von Profiling-Tools wie Xdebug oder Blackfire) hat, dass es sich tatsächlich um einen Engpass handelt. Dies führt zu unleserlichem, komplexem Code, der geschrieben wurde, um Mikrosekunden einzusparen, während Datenbankabfragen oder langsame externe API-Anfragen, die Hunderte von Millisekunden dauern, ignoriert werden. ### Der schlechte Weg: Verschleierte Mikro-Optimierungen Ein Entwickler vermeidet klare PHP-Funktionen und verwendet stattdessen verschachtelte Stringsuchen und bitweise Operationen zur Analyse von Konfigurationsstrings, in dem Glauben, dies sei schneller. ```php // app/Config/Parser.php declare(strict_types=1); namespace App\Config; class Parser { // Cryptic string manipulation to save CPU cycles public function parse(string $data): array { $pos = strpos($data, ':'); if ($pos === false) return []; $key = substr($data, 0, $pos); $val = substr($data, $pos + 1); // Bitwise flag check representing boolean configuration $isFlagged = (int)$val & 1; return [$key => (bool)$isFlagged]; } } ``` ### Der gute Weg: Lesbarkeit steht an erster Stelle Schreiben Sie Code, der leicht zu lesen, zu testen und zu warten ist. Wenn die Performance zu einem Problem wird, führen Sie zuerst ein Profiling durch und optimieren Sie dann dort, wo die tatsächlichen Engpässe liegen. ```php // app/Config/Parser.php declare(strict_types=1); namespace App\Config; class Parser { public function parse(string $jsonString): array { $decoded = json_decode($jsonString, true); if (json_last_error() !== JSON_ERROR_NONE) { return []; } return $decoded; } } ``` --- ## Cargo Cult & Copy-Paste-Programmierung **Cargo-Cult-Programmierung** bezeichnet das Kopieren von Codemustern, Strukturen oder Methoden, ohne zu verstehen, *warum* sie verwendet werden oder welches Problem sie eigentlich lösen. Ein klassisches Beispiel in PHP ist das Kapseln von Laravel-Eloquent-Modellen in einer leeren Repository-Schicht, weil „eine gute Architektur Repositories erfordert“, obwohl Eloquent bereits die Pattern Active Record und Query Builder implementiert. ### Der schlechte Weg: Leerer Repository-Abstraktions-Wrapper Dieses Wrapper-Repository kopiert lediglich die Eloquent-Methoden, bietet keinerlei Abstraktion oder Mehrwert und verdoppelt gleichzeitig die Anzahl der zu wartenden Klassen. ```php // app/Repositories/PostRepositoryInterface.php declare(strict_types=1); namespace App\Repositories; interface PostRepositoryInterface { public function find(int $id); public function create(array $data); } // app/Repositories/EloquentPostRepository.php declare(strict_types=1); namespace App\Repositories; use App\Models\Post; class EloquentPostRepository implements PostRepositoryInterface { public function find(int $id) { return Post::find($id); } public function create(array $data) { return Post::create($data); } } ``` ### Der gute Weg: Active Record direkt verwenden oder echte Abstraktionen schaffen Wenn Ihr Repository den Client nicht vom Persistenzmechanismus isoliert (z. B. weil es ohnehin rohe Eloquent-Abfragen oder -Modelle zurückgibt), verwerfen Sie es und verwenden Sie Eloquent direkt. ```php // app/Http/Controllers/PostController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Models\Post; use Illuminate\Http\JsonResponse; class PostController { public function show(int $id): JsonResponse { // Use active record pattern directly $post = Post::findOrFail($id); return response()->json($post); } } ``` > [!TIP] > **Wann Repositories sinnvoll sind**: Verwenden Sie sie, wenn Sie komplexe Domänenlogik implementieren, die unabhängig vom ORM bleiben muss (z. B. bei Domain-Driven Design), oder wenn Sie wiederverwendbare benutzerdefinierte Abfragen erstellen, die Sie isoliert testen möchten. --- ## Häufige Fehler 1. **Erzwingen von Mustern überall**: Implementieren von Entwurfsmustern in einfachen CRUD-Projekten. 2. **Schreiben von God Classes**: Eine Hilfs- oder Managerklasse unendlich wachsen lassen, anstatt sie in kleine, zusammenhängende Services aufzuteilen. 3. **Optimieren ohne Profiling**: Umschreiben von sauberem PHP-Schleifencode in komplexe Algorithmen, weil man „vermutet“, dass sie langsam sind, während die Datenbank unindizierte Abfragen ausführt. 4. **Blindes Kopieren**: Kopieren fortgeschrittener Enterprise-Muster (wie CQRS, Event Sourcing oder Repository-Schichten) in einfache MVC-Projekte, nur weil sie online populär sind. --- ## Checkliste 1. **SRP-Prüfung:** Hat Ihre Klasse mehr als einen Grund, sich zu ändern? Wenn ja, teilen Sie sie auf. 2. **KISS-Prinzip:** Kann eine einfache `if`-Bedingung oder Hilfsfunktion eine komplexe OOP-Hierarchie ersetzen? 3. **Performance-Profiling:** Haben Sie ein Profiling Ihrer Anwendung mit Xdebug oder Blackfire durchgeführt, bevor Sie Mikro-Optimierungen anwenden? 4. **Mehrwert-Abstraktion:** Verbirgt Ihr Repository oder Ihre Abstraktionsschicht tatsächlich die Implementierungsdetails oder ist es nur ein redundanter Wrapper? --- ## Zusammenfassung Design-Antipatterns sind häufige Fallstricke, die zu starrer, instabiler Software führen. **Spaghetti-Code** entsteht durch mangelnde Trennung der Belange (Separation of Concerns). **God Objects** konsolidieren zu viele Verantwortlichkeiten. Der **Golden Hammer** erzwingt falsche Lösungen für Probleme. **Vorzeitige Optimierung** priorisiert Mikro-Performance gegenüber Lesbarkeit. **Cargo Culting** dupliziert Strukturen, ohne deren architektonischen Wert zu verstehen. Halten Sie den Code einfach, klar und fügen Sie Entwurfsmuster nur dann hinzu, wenn die Komplexität es erfordert. --- ## Selbsttest-Quiz ### Frage 1: Welches SOLID-Prinzip wird direkt verletzt, wenn eine Klasse als „God Object“ fungiert? - A) Open/Closed-Prinzip (OCP) - B) Liskov-Substitutionsprinzip (LSP) - C) Single-Responsibility-Prinzip (SRP)