State Pattern: oggetti che cambiano comportamento in base al proprio stato

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 già 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 complessità 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 a CancelledState. Tutti gli altri metodi lanciano eccezioni appropriate.


• 
  PendingState: pay() processa il pagamento e transiziona a PaidState. cancel() transiziona a CancelledState. ship() lancia "non puoi spedire un ordine non pagato".


• 
  PaidState: ship() registra la spedizione e transiziona a ShippedState. refund() processa il rimborso e transiziona a RefundedState. pay() lancia "ordine già pagato".


• 
  ShippedState: cancel() lancia "non puoi cancellare un ordine già spedito". refund() richiede prima il reso. L'unica transizione valida e verso DeliveredState quando 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 complessità:

• 
  3-4 stati, 2-3 operazioni: l'Enum con match e più semplice e diretto. Lo State Pattern sarebbe over-engineering.


• 
  5+ stati, 4+ operazioni: lo State Pattern scala meglio perché 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 può 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 può 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 può 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.

👉 Leggi l'articolo completo su iadicola.it