Il problema: lo switch sullo stato che divora il codice
Un ordine in un e-commerce ha diversi stati: draft, pending, paid, shipped, delivered, cancelled, refunded. Ogni operazione dipende dallo stato corrente: puoi pagare un ordine solo se e pending, puoi spedire solo se e paid, puoi cancellare solo se non e gia shipped. Il codice diventa una cascata di if ($this->status === 'pending') in ogni metodo.
Il metodo cancel() controlla se lo stato permette la cancellazione. Il metodo ship() controlla se lo stato permette la spedizione. Il metodo refund() controlla se lo stato permette il rimborso. Ogni nuovo stato o nuova operazione richiede di aggiornare tutti i metodi. Ogni nuova transizione richiede di aggiornare tutti i controlli. La complessita cresce come il prodotto di stati per operazioni: 7 stati e 6 operazioni significano 42 condizioni da gestire e mantenere sincronizzate.
Cos'e lo State Pattern: definizione formale
Il Gang of Four definisce lo State come un pattern comportamentale che "permette a un oggetto di alterare il proprio comportamento quando il suo stato interno cambia. L'oggetto sembrera cambiare la propria classe". La struttura prevede tre attori:
- Context: l'oggetto che ha uno stato (es.
Order). Mantiene un riferimento allo State corrente e delega le operazioni a esso. - State: l'interfaccia che dichiara i metodi per ogni operazione (es.
pay(),ship(),cancel()). - ConcreteState: ogni stato (es.
PendingState,PaidState) implementa i metodi con il comportamento specifico di quello stato.
Esempio teorico: ciclo di vita di un ordine
Definiamo l'interfaccia OrderStateInterface con i metodi: pay(Order $order): void, ship(Order $order): void, cancel(Order $order): void, refund(Order $order): void, getStatus(): string.
Ogni stato implementa l'interfaccia:
- DraftState:
pay()lancia un'eccezione ("non puoi pagare un ordine in bozza, prima confermalo").cancel()transiziona aCancelledState. Tutti gli altri metodi lanciano eccezioni appropriate. - PendingState:
pay()processa il pagamento e transiziona aPaidState.cancel()transiziona aCancelledState.ship()lancia "non puoi spedire un ordine non pagato". - PaidState:
ship()registra la spedizione e transiziona aShippedState.refund()processa il rimborso e transiziona aRefundedState.pay()lancia "ordine gia pagato". - ShippedState:
cancel()lancia "non puoi cancellare un ordine gia spedito".refund()richiede prima il reso. L'unica transizione valida e versoDeliveredStatequando il corriere conferma la consegna. - CancelledState e RefundedState: sono stati terminali. Tutti i metodi lanciano eccezioni: nessuna transizione e possibile.
La classe Order ha una proprieta private OrderStateInterface $state e delega ogni operazione: public function pay(): void { $this->state->pay($this); }. Il metodo di transizione Order::transitionTo(OrderStateInterface $newState) e chiamato dagli stati stessi: $order->transitionTo(new PaidState()).
Il vantaggio: aggiungere uno stato senza toccare gli altri
Se arriva un nuovo stato — ad esempio OnHoldState per ordini bloccati in attesa di verifica antifrode — basta creare una nuova classe che implementa OrderStateInterface. Definisci quali operazioni sono permesse in questo stato e quali transizioni sono valide. Nessun altro stato deve cambiare. Nessun metodo della classe Order deve essere modificato. Il principio Open/Closed e rispettato naturalmente.
State Pattern vs Enum con match
In PHP 8.1+ si potrebbe gestire gli stati con un Enum e match:
match($this->status) { OrderStatus::Pending => ..., OrderStatus::Paid => ..., ... }
Funziona per casi semplici, ma ha un limite strutturale: ogni nuovo stato richiede di aggiornare ogni match in ogni metodo. Con lo State Pattern, ogni nuovo stato e autocontenuto nella propria classe. La scelta dipende dalla complessita:
- 3-4 stati, 2-3 operazioni: l'Enum con match e piu semplice e diretto. Lo State Pattern sarebbe over-engineering.
- 5+ stati, 4+ operazioni: lo State Pattern scala meglio perche ogni stato e isolato.
- Transizioni complesse con regole di business: lo State Pattern permette di incapsulare le regole dentro ogni stato.
State Machine come evoluzione
Lo State Pattern puo evolvere in una State Machine formale, dove le transizioni valide sono dichiarate esplicitamente in una mappa: ['pending' => ['paid', 'cancelled'], 'paid' => ['shipped', 'refunded']]. La State Machine aggiunge garanzie: nessuna transizione non dichiarata e possibile, e ogni transizione puo avere guardie (condizioni) e azioni (side effect).
In molti framework questa evoluzione e supportata da librerie dedicate (Symfony Workflow, Laravel State Machines). Ma il concetto alla base e sempre lo State Pattern: il comportamento cambia in base allo stato, e ogni stato sa quali transizioni sono valide.
Quando usare lo State Pattern
- Usa lo State Pattern quando un oggetto ha un numero significativo di stati e il comportamento varia in base allo stato corrente
- Usa lo State Pattern quando gli switch/if sullo stato sono ripetuti in molti metodi della stessa classe
- Usa lo State Pattern quando le regole di transizione sono complesse e vuoi renderle esplicite
- Non usare lo State Pattern per oggetti con 2-3 stati semplici: un boolean o un enum con match bastano
- Non usare lo State Pattern se le transizioni non hanno regole: se ogni stato puo andare in ogni altro stato, il pattern aggiunge struttura senza valore
Lo State Pattern non e un modo elegante di riscrivere degli if: e un modo di rendere esplicite e isolate le regole di comportamento che dipendono dallo stato. Quando queste regole sono complesse, il pattern trasforma un groviglio di condizioni in una struttura leggibile, testabile e manutenibile.