State: Behavior Based on State

Why this matters

An Order moves through: Pending → Processing → Shipped → Delivered → Cancelled. Without the State pattern, every method on Order (ship(), cancel(), deliver()) contains the same long status-checking conditional. Add a new state like "Returning" and you must edit every method. With the State pattern, each state is a class that owns its valid transitions. Adding "Returning" means one new class — existing state classes are untouched.

Un Pedido avanza por: Pendiente → Procesando → Enviado → Entregado → Cancelado. Sin el patrón State, cada método en Order (ship(), cancel(), deliver()) contiene el mismo largo condicional de verificación de estado. Añadir un nuevo estado como "Retornando" requiere editar cada método. Con el patrón State, cada estado es una clase que posee sus transiciones válidas. Añadir "Retornando" significa una nueva clase — las clases de estado existentes no se tocan.

✗ The problem

✓ The solution

State machines at scaleMáquinas de estado a escala

For simple cases with a handful of states, the pattern is self-contained. For complex workflows with dozens of states, consider a dedicated state-machine library (XState for TypeScript, transitions for Python). These libraries add guard conditions, entry/exit actions, and visualization — the State pattern is still the conceptual foundation.

Para casos simples con un puñado de estados, el patrón es autocontenido. Para flujos de trabajo complejos con docenas de estados, considera una biblioteca dedicada de máquinas de estado (XState para TypeScript, transitions para Python). Estas bibliotecas añaden condiciones de guarda, acciones de entrada/salida y visualización — el patrón State sigue siendo la base conceptual.