State

Permite a un objeto cambiar de comportamiento al cambiar su estado interno; parece cambiar de clase.

Contexto

Un pedido pasa por: Draft → Placed → Paid → Shipped → Delivered. En cada estado, las acciones permitidas cambian.

Problema

Si lo modelas con if (status == ...) en cada método, tendrás switches gigantes y duplicación.

Solución

Cada estado es una clase con su comportamiento. La entidad delega en el estado actual y permite la transición.

#Ejemplo en C#

public abstract class OrderState
{
    public virtual void Pay(Order o)   => throw new InvalidOperationException();
    public virtual void Ship(Order o)  => throw new InvalidOperationException();
}

public class Placed   : OrderState { public override void Pay(Order o)  => o.SetState(new Paid()); }
public class Paid     : OrderState { public override void Ship(Order o) => o.SetState(new Shipped()); }
public class Shipped  : OrderState { }

public class Order
{
    private OrderState _state = new Placed();
    public void SetState(OrderState s) => _state = s;
    public void Pay()  => _state.Pay(this);
    public void Ship() => _state.Ship(this);
}

Cuándo NO aplicarlo

Si solo hay 2-3 estados con poca lógica diferenciada: un enum + switch basta.

Tradeoffs

Pro	Contra
Elimina ifs y switches	Más clases
Estados explícitos y testeables	Las transiciones quedan dispersas

#behavioral #gof #fsm