User registered!
"; } else { echo "Email already exists.
"; } } else { echo "Invalid email.
"; } } ?> ``` ### The Good Way: Separation of Concerns We refactor this by separating database interaction (Repository), business/validation rules (Controller), and visual presentation (Blade/Template). ```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!"; } } ``` --- ## The God Object A **God Object** is a monolithic class that knows too much or does too much. It concentrates all the application's intelligence, violating the **Single Responsibility Principle (SRP)**. Other classes in the system become dummy data holders (anemic models) controlled by this giant class. ### The Bad Way: A Monolithic OrderManager Here, a single class handles payment gateway connection, database saving, email sending, discount calculations, and PDF generation. ```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); } } ``` ### The Good Way: Decoupled Services We refactor by delegating each domain task to a dedicated component, keeping the manager class as a lightweight coordinator. ```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); } } ``` --- ## The Golden Hammer The **Golden Hammer** is the assumption that a favorite technology or design pattern is universally applicable: *"If all you have is a hammer, everything looks like a nail."* In PHP, this often happens when developers try to use complex structural/behavioral patterns (e.g. State or Visitor) for simple tasks, leading to unnecessary class explosions, or using a database engine (like Elasticsearch or Redis) for tasks that could easily be done directly in SQL. ### The Bad Way: Forcing the State Pattern on a Simple Age Check A developer wants to check if a user is allowed to purchase alcohol. Instead of a simple condition, they build an entire State Pattern machinery with multiple interfaces and concrete classes. ```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(); } } ``` ### The Good Way: Keep It Simple (KISS) Design patterns add complexity and cognitive load. If the business logic is simple, write it simply. ```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] > **Use patterns when complexity warrants them**: Design patterns are built to handle changing requirements and high complexity. If your state logic only has one simple condition that will never change, a design pattern is a form of over-engineering. --- ## Premature Optimization **Premature Optimization** is optimizing code for performance before you have concrete proof (via profiling tools like Xdebug or Blackfire) that it is actually a bottleneck. This leads to unreadable, complex code written to save microseconds, while ignoring database queries or slow external API requests that take hundreds of milliseconds. ### The Bad Way: Obfuscated Micro-Optimizations A developer avoids clear PHP functions and uses nested string searches and bitwise operations to parse configuration strings, thinking it's faster. ```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]; } } ``` ### The Good Way: Readable Code First Write code that is easy to read, test, and maintain. If performance becomes an issue, profile first, then optimize where the bottlenecks are. ```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 Programming **Cargo Cult Programming** is the practice of copying code patterns, structures, or methodologies without understanding *why* they are used or what problem they solve. A classic example in PHP is wrapping Laravel Eloquent models in an empty Repository Layer because "good architecture requires repositories," even though Eloquent already implements the Active Record and Query Builder patterns. ### The Bad Way: Empty Repository Abstraction Wrapper This wrapper repository merely copies Eloquent methods, adding zero abstraction or value while introducing double the classes to maintain. ```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); } } ``` ### The Good Way: Use Active Record Directly or Create Real Abstractions If your repository doesn't insulate the client from the persistence mechanism (e.g. returning raw Eloquent queries or models anyway), discard it and use Eloquent directly. ```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] > **When to use repositories**: Use them when you are implementing complex domain logic that needs to remain independent of the ORM (e.g., in Domain-Driven Design), or when you are building reusable custom queries that you want to test in isolation. --- ## Common Mistakes 1. **Forcing Patterns Everywhere**: Implementing design patterns in simple CRUD projects. 2. **Writing God Classes**: Letting a helper or manager class grow infinitely instead of breaking it down into small, cohesive services. 3. **Optimizing without Profiling**: Rewriting clean PHP loops into complex algorithms because you "suspect" they are slow, while the database runs unindexed queries. 4. **Blind Copying**: Copying advanced enterprise patterns (like CQRS, Event Sourcing, or repository layers) into simple MVC projects just because they are popular online. --- ## Checklist 1. **SRP Check:** Does your class have more than one reason to change? If so, break it down. 2. **KISS Principle:** Can a simple `if` condition or helper function replace a complex OOP hierarchy? 3. **Performance profiling:** Have you profiled your application using Xdebug or Blackfire before applying micro-optimizations? 4. **Value-Added Abstraction:** Does your repository or abstraction layer actually hide the implementation details, or is it just a redundant wrapper? --- ## Summary Design antipatterns are common pitfalls that lead to rigid, fragile software. **Spaghetti Code** results from a lack of separation of concerns. **God Objects** consolidate too many responsibilities. The **Golden Hammer** forces wrong solutions onto problems. **Premature Optimization** prioritizes micro-performance over readability. **Cargo Culting** duplicates structures without understanding their architectural value. Keep code simple, clear, and only add design patterns when complexity demands them. --- ## Self-Test Quiz ### Question 1: Which SOLID principle is directly violated when a class acts as a "God Object"? - A) Open/Closed Principle (OCP) - B) Liskov Substitution Principle (LSP) - C) Single Responsibility Principle (SRP)