User registered!
"; } else { echo "Email already exists.
"; } } else { echo "Invalid email.
"; } } ?> ``` ### La forma correcta: Separación de conceptos Refactorizamos esto separando la interacción con la base de datos (Repositorio), las reglas de negocio/validación (Controlador) y la presentación visual (Blade/Plantilla). ```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!"; } } ``` --- ## El God Object Un **God Object** (objeto dios) es una clase monolítica que sabe demasiado o hace demasiado. Concentra toda la inteligencia de la aplicación, violando el **Principio de Responsabilidad Única (SRP)**. Otras clases en el sistema se convierten en meros contenedores de datos (modelos anémicos) controlados por esta clase gigante. ### La forma incorrecta: Un OrderManager monolítico Aquí, una sola clase maneja la conexión a la pasarela de pago, el guardado en la base de datos, el envío de correos electrónicos, los cálculos de descuento y la generación de PDF. ```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); } } ``` ### La forma correcta: Servicios desacoplados Refactorizamos delegando cada tarea del dominio a un componente dedicado, manteniendo la clase administradora (manager) como un coordinador ligero. ```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); } } ``` --- ## El Golden Hammer El **Golden Hammer** (martillo de oro) es la suposición de que una tecnología o patrón de diseño favorito es de aplicación universal: *"Si la única herramienta que tienes es un martillo, todo lo que ves parece un clavo."* En PHP, esto sucede a menudo cuando los desarrolladores intentan usar patrones estructurales/de comportamiento complejos (por ejemplo, State o Visitor) para tareas sencillas, lo que provoca una explosión innecesaria de clases, o cuando utilizan un motor de base de datos (como Elasticsearch o Redis) para tareas que podrían realizarse fácilmente de forma directa en SQL. ### La forma incorrecta: Forzar el patrón State para una comprobación de edad simple Un desarrollador quiere comprobar si un usuario tiene permitido comprar alcohol. En lugar de usar una condición simple, construye toda una maquinaria del patrón State con múltiples interfaces y clases concretas. ```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(); } } ``` ### La forma correcta: Manténlo simple (KISS) Los patrones de diseño añaden complejidad y carga cognitiva. Si la lógica de negocio es simple, escríbela de manera simple. ```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] > **Usa patrones cuando la complejidad lo justifique**: Los patrones de diseño están creados para manejar requisitos cambiantes y una alta complejidad. Si la lógica de tu estado solo tiene una condición simple que nunca cambiará, un patrón de diseño es una forma de sobreingeniería. --- ## Optimización prematura La **Optimización prematura** consiste en optimizar el código para mejorar el rendimiento antes de tener pruebas concretas (a través de herramientas de perfilado como Xdebug o Blackfire) de que es realmente un cuello de botella. Esto conduce a un código complejo e ilegible escrito para ahorrar microsegundos, mientras se ignoran las consultas a la base de datos o las solicitudes lentas a APIs externas que tardan cientos de milisegundos. ### La forma incorrecta: Microoptimizaciones ofuscadas Un desarrollador evita el uso de funciones claras de PHP y utiliza búsquedas de cadenas anidadas y operaciones a nivel de bits para analizar cadenas de configuración, pensando que es más rápido. ```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]; } } ``` ### La forma correcta: Priorizar el código legible Escribe código que sea fácil de leer, probar y mantener. Si el rendimiento se convierte en un problema, realiza un perfilado primero, luego optimiza allí donde estén los cuellos de botella. ```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 y programación de copiar y pegar La **Programación de culto al cargo** (Cargo Cult Programming) es la práctica de copiar patrones, estructuras o metodologías de código sin comprender *por qué* se usan o qué problema resuelven. Un ejemplo clásico en PHP es envolver los modelos Eloquent de Laravel en una capa de repositorio vacía porque "una buena arquitectura requiere repositorios", a pesar de que Eloquent ya implementa los patrones Active Record y Query Builder. ### La forma incorrecta: Envoltorio (wrapper) vacío de abstracción de repositorio Este repositorio envoltorio simplemente copia los métodos de Eloquent, agregando cero abstracción o valor, al tiempo que introduce el doble de clases para mantener. ```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); } } ``` ### La forma correcta: Usar Active Record directamente o crear abstracciones reales Si tu repositorio no aísla al cliente del mecanismo de persistencia (por ejemplo, si devuelve consultas o modelos Eloquent sin procesar de todos modos), deséchalo y utiliza Eloquent directamente. ```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] > **Cuándo usar repositorios**: Úsalos cuando estés implementando una lógica de dominio compleja que deba permanecer independiente del ORM (por ejemplo, en Diseño Guiado por el Dominio o DDD), o cuando estés creando consultas personalizadas reutilizables que desees probar de forma aislada. --- ## Errores comunes 1. **Forzar patrones en todas partes**: Implementar patrones de diseño en proyectos CRUD simples. 2. **Escribir clases Dios (God Classes)**: Permitir que una clase helper o manager crezca infinitamente en lugar de dividirla en servicios pequeños y cohesivos. 3. **Optimizar sin perfilar**: Reescribir bucles PHP limpios en algoritmos complejos porque "sospechas" que son lentos, mientras la base de datos ejecuta consultas sin índices. 4. **Copia ciega**: Copiar patrones empresariales avanzados (como CQRS, Event Sourcing o capas de repositorio) en proyectos MVC simples solo porque son populares en internet. --- ## Lista de verificación 1. **Comprobación de SRP:** ¿Tiene tu clase más de una razón para cambiar? Si es así, divídela. 2. **Principio KISS:** ¿Puede una condición `if` simple o una función helper reemplazar una jerarquía compleja de POO? 3. **Perfilado de rendimiento:** ¿Has perfilado tu aplicación usando Xdebug o Blackfire antes de aplicar microoptimizaciones? 4. **Abstracción con valor añadido:** ¿Tu repositorio o capa de abstracción realmente oculta los detalles de implementación, o es solo un envoltorio redundante? --- ## Resumen Los antipatrones de diseño son errores comunes que conducen a un software rígido y frágil. El **Código Spaghetti** surge de la falta de separación de conceptos. Los **God Objects** consolidan demasiadas responsabilidades. El **Golden Hammer** impone soluciones incorrectas a los problemas. La **Optimización prematura** prioriza el rendimiento a pequeña escala sobre la legibilidad. La **Programación de culto al cargo (Cargo Culting)** duplica estructuras sin comprender su valor arquitectónico. Mantén el código simple, claro y solo añade patrones de diseño cuando la complejidad lo exija. --- ## Prueba de autoevaluación ### Pregunta 1: ¿Qué principio SOLID se viola directamente cuando una clase actúa como un "God Object"? - A) Principio de Abierto/Cerrado (OCP) - B) Principio de Sustitución de Liskov (LSP) - C) Principio de Responsabilidad Única (SRP)