Quali sono i design pattern comuni nei framework PHP?

Question

Accepted Answer

I framework PHP (Laravel, Symfony) sono costruiti su **design pattern** classici — soluzioni riutilizzabili a problemi comuni di progettazione. Riconoscerli ti aiuta a capire come funzionano i framework e a scrivere codice meglio strutturato.

## MVC (Model-View-Controller) — la fondazione architettonica

```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 — astrazione dell'accesso ai dati

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

Il pattern **Repository** astrae l'accesso ai dati dietro un'interfaccia — disaccoppiando la logica di business dal database e facilitando i test.

## Factory — incapsulare la creazione di oggetti

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

## Altri pattern comuni nei framework 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 in particolare mostra questi: **Facades** (proxy statici ai servizi), **Active Record** (modelli Eloquent), **Observer** (event/model observer), **Strategy** (driver intercambiabili per cache, queue, auth).

## Perché è importante

I design pattern sono una conoscenza importante per gli sviluppatori PHP perché i framework principali (Laravel, Symfony) sono costruiti interamente su di essi — quindi comprendere i pattern è essenziale sia per capire *come funzionano questi framework* che per scrivere codice ben strutturato.

Riconoscere **MVC** (la fondazione architettonica di quasi ogni framework web PHP), **Dependency Injection / IoC container** (come i framework collegano le dipendenze per il disaccoppiamento e la testabilità), il pattern **Repository** (astrarre l'accesso ai dati per la persistenza testabile e intercambiabile), e i pattern specifici dei framework come **Facades** di Laravel (proxy statici ai servizi), **Active Record** (modelli Eloquent), e **Observer** (event) demistifica la "magia" di questi framework e ti permette di usarli ed estenderli efficacemente.

Al di là della comprensione dei framework, conoscere i pattern comuni ti dà un vocabolario condiviso per le discussioni di progettazione, soluzioni provate a problemi ricorrenti, e la capacità di progettare codice mantenibile e flessibile.

Poiché lo sviluppo PHP professionale avviene quasi sempre all'interno di framework ricchi di pattern, e poiché un buon design dell'applicazione si basa su un uso appropriato dei pattern, comprendere i design pattern comuni — cosa risolvono e dove compaiono nell'ecosistema PHP — è una conoscenza di livello senior che distingue gli sviluppatori che comprendono profondamente i loro strumenti e possono costruire applicazioni ben architetturate da coloro che usano i framework superficialmente. (L'avvertenza, come sempre: i pattern sono strumenti per problemi reali, non obiettivi — applicarli dove non si adattano aggiunge una complessità inutile.)