¿Qué patrones de diseño son comunes en frameworks PHP?

Question

Accepted Answer

Los frameworks PHP (Laravel, Symfony) se construyen sobre **patrones de diseño** clásicos — soluciones reutilizables a problemas de diseño comunes. Reconocerlos te ayuda a entender cómo funcionan los frameworks y a escribir código mejor estructurado.

## MVC (Model-View-Controller) — la base arquitectónica

```text
Model      → data + business logic (e.g. Eloquent models)
View       → presentation (templates: Blade, Twig)
Controller → handles requests, coordinates models & views
→ The structural pattern of nearly every PHP web framework.
```

## Dependency Injection / IoC Container

```php
// frameworks use a container to resolve & inject dependencies (decoupling, testability)
$service = $container->get(UserService::class);   // dependencies auto-wired
```

## Repository pattern — abstraer acceso a datos

```php
interface UserRepository {
    public function find(int $id): ?User;
}
class EloquentUserRepository implements UserRepository { /* DB-specific impl */ }
// services depend on the INTERFACE → swap data sources, mock in tests
```

El patrón **Repository** abstrae el acceso a datos detrás de una interfaz — desacoplando la lógica de negocio de la base de datos y facilitando las pruebas.

## Factory — encapsular la creación de objetos

```php
class PaymentFactory {
    public static function create(string $type): PaymentGateway {
        return match($type) {
            'stripe' => new StripeGateway(),
            'paypal' => new PayPalGateway(),
        };
    }
}
```

## Otros patrones comunes en frameworks PHP

```text
Singleton  → one shared instance (often via the DI container, e.g. config, DB connection)
Observer   → event/listener systems (Laravel events, model observers)
Strategy   → interchangeable algorithms (e.g. different cache/auth drivers)
Decorator  → wrap to add behavior (middleware-style request/response wrapping)
Facade     → a simple static interface to complex subsystems (Laravel Facades:
             Cache::get(), DB::table() — proxy to container-resolved services)
Adapter    → uniform interface over different implementations (e.g. filesystem drivers)
Active Record → models that wrap DB rows with query/save methods (Eloquent)
```

Laravel especialmente exhibe estos: **Facades** (proxies estáticos a servicios), **Active Record** (modelos Eloquent), **Observer** (eventos/observadores de modelos), **Strategy** (drivers intercambiables para cache, queue, auth).

## Por qué es importante

Los patrones de diseño son conocimiento importante para desarrolladores PHP porque los frameworks principales (Laravel, Symfony) están construidos enteramente sobre ellos — así que entender patrones es esencial tanto para comprender *cómo funcionan estos frameworks* como para escribir código bien estructurado.

Reconocer **MVC** (la base arquitectónica de casi todo framework web PHP), **Dependency Injection / IoC containers** (cómo los frameworks conectan dependencias para desacoplamiento y testabilidad), el patrón **Repository** (abstrayendo acceso a datos para persistencia testeable e intercambiable), y patrones específicos del framework como **Facades** de Laravel (proxies estáticos a servicios), **Active Record** (modelos Eloquent), y **Observer** (eventos) desmitifica la "magia" de estos frameworks y te permite usarlos y extenderlos efectivamente.

Más allá de entender frameworks, conocer patrones comunes te da un vocabulario compartido para discusiones de diseño, soluciones probadas a problemas recurrentes, y la capacidad de arquitectar código mantenible y flexible.

Ya que el desarrollo profesional de PHP casi siempre ocurre dentro de frameworks cargados de patrones, y ya que el buen diseño de aplicaciones se basa en el uso apropiado de patrones, entender los patrones de diseño comunes — qué resuelven y dónde aparecen en el ecosistema PHP — es conocimiento valioso de nivel senior que distingue desarrolladores que entienden profundamente sus herramientas y pueden construir aplicaciones bien arquitectadas de aquellos que usan frameworks superficialmente. (La salvedad, como siempre: los patrones son herramientas para problemas reales, no objetivos — aplicarlos donde no encajan añade complejidad innecesaria.)