Facade Pattern

La primera vez que escuche la palabra Facade en una reunión donde se hablaba de sistemas, me pareció un concepto fuera de lugar o al menos que se usaba con la intensión de ser presuntuoso. Sobre todo porque la persona que lo estaba usando en la junta, no es una persona que se dedique a escribir código…al ser teórico, sabe términos, pero no siempre sabe aplicarlos en el momento adecuado. En fin, la situación termino con una búsqueda en internet.

Cuando leí del patrón, me di cuenta porque se me hacía que la palabra estaba sobre empleada, resulta que al igual que todos los patrones no son la solución a todos nuestros problemas, y al parece esta persona solo me hablaba de un Facade para todo. En fin, dejemos el chisme y veamos nuestro patrón.

 

Facade

Este patrón define una interface de alto nivel, la cual sirve para simplificar el acceso y el uso de sub sistemas. Curiosamente, este patrón es uno de los más usados, así como fácil de usar. Su objetivo es ocultar por medio de una interface simple sistemas más complejos.

Es probable que lo hayamos usado muchas veces, mas de las que nos hayamos dado cuenta, lo que pasa es que no lo reconocíamos.

 

Cuando se debe usar?

Cuando tenemos que enfrentarnos a un sistema complejo con muchas clases, especializadas, que se deben usar en conjunto. Un ejemplo común seria un mecanismo de ventas en línea, que interactúa con otros subsistemas registro, existencias, carro de compras, API de acceso al banco, mismos que no tenemos que usar de forma directa.

 

Porque es útil?

Nos permite crear una única interface por medio de la cual podemos exponer los métodos apropiados, para tareas que resulten comunes, y al permitirnos encapsular la lógica entre varias bibliotecas, hace que nuestro código sea más fácil de entender y de usar. Además reduce las dependencias hacia el exterior.

 

En la vida real

Todos los días interactuamos con servicios de todo tipo; desde empleados de tras de un mostrador hasta sistemas web. Por ejemplo cuando interactuamos con un empleado, el es quien interactúa con los sistemas internos de la empresa, nosotros no tenemos ese acceso, sin embargo sabemos que por medio de este empleado tendremos nuestro recibo por la compra, y nos llevaremos nuestro producto, que se movió de un sistema de almacén y nos fue entregado y facturado. El empleado es un ejemplo del patrón Facade.

 

Requerimientos

El proyecto en el que estoy trabajando actualmente, se basa en un Framework que ofrece todos los servicios necesarios para atender a los clientes de la empresa. Uno de los mecanismos más interesantes que se deben resolver consiste en crear un componente que pueda atender solicitudes de diferentes páginas, llenando la información adecuada en las áreas correspondientes. Las áreas por lo general son de un solo tipo; sin embargo una de las áreas tiene la particularidad que puede presentar información de diferente naturaleza, por ejemplo: Publicidad interna, Promoción de servicios, Anuncios de Socios comerciales, cupones de descuento, los cuales son sub sistemas de mercadotecnia y ventas.

 

Análisis

Como podemos ver en los requerimientos, hay varios componentes atendido cada servicio, lo que ocasionaría que un cliente que requiera esta información, tendría que interactuar con más de un componente y desde luego tendría que saber el orden, para poder atender el requerimiento de esta área; esto se ve como un escenario adecuado para un patrón Facade.

 

Mano a la obra

Con la intensión de simplificar el ejemplo, y concentrarnos en la estructura, usare NBuilder  esta biblioteca, facilita la creación de datos para testear nuestro código; les recomiendo que la usen.

En esta ocasión lo primero que haremos será crear algunos componentes de ejemplo, para representar los que se explicaron en los requerimientos; todos usaran una clase como elemento primario para construir su información.

La clase de uso común define un elemento que debe llenarse con los datos de cada componente para que sean presentados de forma similar, la clase es esta:

Los componentes deben implementar una interface que contiene un único método y devuelve una lista de nuestra clase Item:

Todos los componentes son iguales, en nuestro ejemplo. Así que no agregare los demás, pero su código es el mismo, solo deben cambiar el nombre del método y la clase. Este es el código del componente de Anuncios:

Aquí es donde usamos NBuilder para crear 5 elementos y sustituir el valor que crea de forma automática por un texto fijo,

Nuestra clase Facade expone un único método:

aun que podría exponer más métodos; lo interesante a notar aquí es que la lógica para determinar que se debe incluir en los datos a devolver, se encapsula en esta clase. En el ejemplo no incluí esta lógica, porque no viene al caso, sin embargo en donde dice Caso 1, Caso 2, etc., se podrían escribir validaciones que determinarían si estos datos se deben incluir o no. De esta manera el cliente que solicite esta información, no tendría por qué saber nada de esta lógica y seria un simple consumidor de los datos.

Para testearlo, creamos nuestra acostumbrada aplicación de consola:

El resultado sería este:

Con un poco de lógica en la clase Marketing, podemos determinar si se presentaran Anuncios, o Cupones, o Promociones. Y de esta manera no veríamos todo.

El poder del código solo es completo, si tenemos el conocimiento de como usarlo.