Hace ya un tiempo comente cuales son los principales patrones de diseño y hice una entrada con un ejemplo del patrón de diseño Command. En esta entrada pondré un ejemplo del patrón de diseño State.
El patrón de diseño State nos puede ser de mucha utilidad en los casos que por ejemplo una entidad tenga asociado un grafo de estados con transiciones permitidas y no permitidas entre algunos estados. En función del estado, sus datos y la transición la entidad puede comportarse de forma diferente. Por ejemplo, supongamos que tenemos una entidad Compra que a lo largo de su vida en la aplicación pasa por diferentes estados:
- creada: la compra se acaba de crear.
- en espera: se ha hecho una compra y se está esperando que el pago sea correcto.
- verificada: el pago es correcto y se está esperando a enviar el producto.
- cancelada: la compra se ha cancelado porque el usuario no quiere ya el producto, no hay existencias u otro motivo.
- enviada: el pedido ha sido enviado.
- comprar: la compra pasa de creada a en espera de verificarla.
- verificar: la compra pasa de en espera a verificada y esperando a enviarse.
- cancelar: la compra se puede cancelar excepto una vez que ya se ha enviado.
- enviar: la compra se envía al usuario y ya no puede cancelarse.
Si diseñamos este flujo de estados sin el patrón State probablemente acabemos con una clase con un montón de condiciones y métodos de bastantes líneas sin una organización clara a simple vista. Para evitarlo aplicaremos el patrón State a este pequeño flujo de estados. En cuanto a código este patrón se basa en dos ideas:
- Cada estado será representado una clase.
- Cada una de estas clases contendrá un método por cada posible transición.
Según el diagrama de estados y transiciones no todas las transiciones son posibles, una compra en espera no puede enviarse. Pero en el código estamos haciendo que todos los estados tengan todos los métodos que representan todas las transiciones, la forma de hacer en el código que una transición no sea posible para un determinado estado es lanzando una excepción en su correspondiente método, el método enviar del estado en espera, lanzará una excepción ya que es este estado aún la compra no puede enviarse. La clase abstracta AbstractState implementará la interfaz CompraState y lanzará una excepción en todos los métodos, las clases que extiendan de esta podrán redefinir los métodos que necesiten utilizando la propiedad de la programación orientada a objetos del polimorfismo, esta clase abstracta nos permitirá implementar en cada clase de estado únicamente los métodos con las transiciones válidas. Las clases nos podrían quedar de la siguiente forma:
Para que los métodos puedan acceder y manipular los datos de la compra se les pasa como parámetro en el constructor. La factoría CompraStateFactory encapsula la lógica para construir cada uno de los estados. La implementación de cada uno de los estado podría ser la siguiente.
Finalmente, la clase Compra podría ser de la siguiente forma:
El patrón State puede facilitarnos bastante la vida como programadores pero si el diagrama de estados fuese más complejo, con mucha lógica de negocio y el flujo dependiense de información independiente de la compra quizá deberíamos evaluar su si un motor de procesos (BPMS) como Activiti y un sistema de reglas de negocio (BRMS) como Drools sería más adecuado.
El código fuente completo de ejemplo los puedes obtener de mi repositorio de github con los siguiente comandos:
Referencia:
Patrones de diseño en la programación orientada a objetos
Ejemplo del patrón de diseño Command y programación concurrente en Java
Ejemplo del patrón de diseño No Operation
