Quais padrões de design são comuns em frameworks PHP?

Question

Accepted Answer

Frameworks PHP (Laravel, Symfony) são construídos sobre **padrões de design** clássicos — soluções reutilizáveis para problemas comuns de design. Reconhecê-los ajuda você a entender como os frameworks funcionam e a escrever código melhor estruturado.

## MVC (Model-View-Controller) — a fundação arquitetural

```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 — abstrair acesso a dados

```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
```

O padrão **Repository** abstrai o acesso a dados atrás de uma interface — desacoplando a lógica de negócio do banco de dados e auxiliando testes.

## Factory — encapsular criação de objetos

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

## Outros padrões comuns em 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 demonstra estes: **Facades** (proxies estáticos para serviços), **Active Record** (modelos Eloquent), **Observer** (eventos/observadores de modelo), **Strategy** (drivers intercambiáveis para cache, fila, autenticação).

## Por que isso importa

Padrões de design são conhecimento importante para desenvolvedores PHP porque os principais frameworks (Laravel, Symfony) são construídos inteiramente sobre eles — então entender padrões é essencial tanto para compreender *como estes frameworks funcionam* quanto para escrever código bem estruturado.

Reconhecer **MVC** (a fundação arquitetural de praticamente todo framework web PHP), **Dependency Injection / contêineres IoC** (como frameworks conectam dependências para desacoplamento e testabilidade), o padrão **Repository** (abstraindo acesso a dados para persistência testável e intercambiável), e padrões específicos de framework como **Facades** do Laravel (proxies estáticos para serviços), **Active Record** (modelos Eloquent), e **Observer** (eventos) desmistifica a "mágica" desses frameworks e permite usá-los e estendê-los efetivamente.

Além de entender frameworks, conhecer padrões comuns oferece um vocabulário compartilhado para discussões de design, soluções comprovadas para problemas recorrentes, e a habilidade de arquitetar código mantível e flexível.

Como desenvolvimento PHP profissional quase sempre acontece dentro de frameworks pesados em padrões, e como o bom design de aplicação depende do uso apropriado de padrões, entender os padrões de design comuns — o que eles resolvem e onde aparecem no ecossistema PHP — é conhecimento valioso de nível sênior que distingue desenvolvedores que entendem profundamente suas ferramentas e podem construir aplicações bem arquitetadas daqueles que usam frameworks superficialmente. (A ressalva, como sempre: padrões são ferramentas para problemas reais, não objetivos — aplicá-los onde não se encaixam adiciona complexidade desnecessária.)