Patrón estado

Desde un tiempo a esta parte he llegado a la conclusión que el software nunca se termina de hacer y creer que con un proceso X,Y o Z se tendrá "The definitive software" es absolutamente falso. En base a esto la vuelta de tuerca es estar preparado y siempre listo (Sí, soy Scout) para los cambios que de seguro ocurrirán en nuestro diseño, para ello - y tal como mi gran profesor Nelson Medinilla me enseñó - hay que agregar "Ambiguedad" al diseño pues es muy comprometedor nombrar un método de forma cerrada, por ejemplo: "calcularTasas" - es mejor usar "calcular" o mejor "operar" por que si hay cambios los metemos dentro de un método que está preparado para ser extendido en su funcionalidad.

Siempre es buena práctica encapsular lo que varía y una fuente de variación en el comportamiento de una classe es su estado - la otra fuente que se me viene a la cabeza es el tipo que se soluciona con el Patrón Estrategia - ¿Adivinen qué? Existe un patrón llamado estado.

La idea del patrón estado es encapsular - aislar las operaciones que dependan del estado o que se pueden graficar en una máquina de estados.

Supongamos una clase Impresora , los estados serían : ImpresoraApagada - ImpresoraImprimiendo - ImpresoraEsperando - ImpresoraLimpiandose, la operación de ejemplo que depende del estado sería - en un principio - imprimir o mejor aún la más ambigua "operar()"; luego a alguien se le ocurrirá algún chequéo de tinta antes de imprimir.

Seguramente algien podría hacer funcionar esta clase simplemente con un switch dentro de imprimir, pero el problema viene cuando deseas ampliar los estados y sus transiciones; necesariamente debes intervenir el switch y agregar esta nueva opción.

La solución elegante es "encapsular lo que varía" y "favorecer la composicion por sobre la herencia", así pues tenemos la Clase impresora con un atributo llamado EstadoActual, es este atributo el que vamos cambiando y es de tipo EstadoImpresora - que es una clase abstracta o interface si así lo quieren.

Al diseñar la clase Impresora podríamos crearla con un estado por defecto e implementar los cambios de estado dentro de la misma clase o en cada clase estado definiendo el siguiente estado cuando el caso lo amerite; para este ejemplo el cambio automático de estado con una máquina de estados no lo considero por que me cae muy mal Craig Larman.

Classe:
Nombre: Impresora
Atributos: EstadoImpresora estadoActual
Metodos: imprimir()


Descargar el código aca