💡 Ver Caso Práctico: Ejemplo Práctico del Patrón State
State (Estado) es un patrón de diseño comportamental que permite a un objeto cambiar su comportamiento cuando cambia su estado interno. El objeto parece cambiar de clase.
Propósito y Caso de Uso
Utiliza State cuando el comportamiento de un objeto dependa de su estado actual y ese comportamiento cambie en tiempo de ejecución (ej. un pedido: pendiente → pagado → enviado → entregado, cada uno con transiciones y reglas distintas). Evita máquinas de estado implementadas con if/switch gigantes sobre una variable de estado.
Estructura del Patrón
- Estado (Interfaz): Declara métodos comunes a todos los estados.
- Estados Concretos: Implementan el comportamiento específico de cada estado y deciden la siguiente transición.
- Contexto: Mantiene una referencia al estado actual y delega el comportamiento en él.
Flujo de Funcionamiento
- Delegación: El contexto invoca un método sobre su estado actual (ej.
pay()). - Comportamiento específico: El estado ejecuta la lógica válida para esa fase.
- Transición: El propio estado asigna el siguiente estado al contexto, cambiando su comportamiento futuro.
Ejemplos de Implementación Reales
interface OrderState {
pay(order: Order): void;
ship(order: Order): void;
}
class PendingState implements OrderState {
pay(order: Order) { console.log('Pago recibido'); order.setState(new PaidState()); }
ship() { throw new Error('No se puede enviar un pedido sin pagar'); }
}
class PaidState implements OrderState {
pay() { throw new Error('Ya está pagado'); }
ship(order: Order) { console.log('Pedido enviado'); order.setState(new ShippedState()); }
}
class ShippedState implements OrderState {
pay() { throw new Error('Pedido ya enviado'); }
ship() { throw new Error('Ya fue enviado'); }
}
class Order {
private state: OrderState = new PendingState();
setState(state: OrderState) { this.state = state; }
pay() { this.state.pay(this); }
ship() { this.state.ship(this); }
}
const order = new Order();
order.pay(); // Pago recibido
order.ship(); // Pedido enviadoCuándo NO usarlo
Si el objeto solo tiene 2 estados simples sin transiciones complejas, un booleano o enum con un if es suficiente (YAGNIGlosarioYAGNI (You Aren't Gonna Need It)Principio de Extreme Programming (XP) que establece que un programador no debe añadir funcionalidad hasta que sea estrictamente necesario. Su objetivo es evitar la sobre-ingeniería (over-engineering), previniendo código para funcionalidades hipotéticas.Ver término completo →).