SESSION FACADE

El patrón Fachada proporciona una interfaz unificada de alto nivel para un subsistema, que oculta las interfaces de bajo nivel de las clases que lo implementan. Con esto se consiguen dos objetivos fundamentales: hacer el subsistema más fácil de usar y desacoplar a los clientes de las clases del subsistema.

Crea una fachada para encapsular las complejas interrelaciones de los distintos elementos de negocio.

Proporciona un servicio uniforme y maneja el flujo de ejecución de los subelementos.

Por todo esto se deberá aplicar el patrón Fachada cuando se de alguna de las siguientes circunstancias:

En general cuando por algún motivo se desee dotar de una interfaz sencilla y usable a un subsistema complejo. Una fachada proporciona una vista por defecto de la funcionalidad del subsistema suficiente para la mayoría de los programadores.

Cuando se detecten demasiadas dependencias entre las clases clientes de una abstracción y las clases que implementan esta abstracción en un subsistema. En este caso debe introducirse una fachada que permita diseñar a los clientes y otros subsistemas para que dependan de una interfaz y no de una implementación. Cuando se quiera estructurar un sistema en subsistemas siguiendo un patrón de capas. Será de gran ayuda dotar de una fachada a cada nivel de subsistemas y utilizarla como punto de acceso al mismo. De este modo se simplificará al máximo el mantenimiento de las dependencias entre niveles. Cuando se tenga un subsistema que ofrece una funcionalidad muy rica y compleja y un conjunto significativo de clientes que solo necesitan usar una parte reducida de la misma.

Estructura

El patrón Fachada pertenece a la categoría de patrones con propósito estructural y alcance de objeto. Es decir, propone una manera de componer a sus participantes, en este caso objetos, mediante relaciones determinadas dinámicamente en tiempo de ejecución.

 Ventajas

• Desde el punto de vista de los clientes, la fachada los aísla de los componentes del subsistema minimizando el número de objetos con los que tienen que tratar para obtener un servicio. De este modo los clientes son mucho más fáciles de escribir pues el subsistema es más sencillo de utilizar.
• Desde el punto de vista del subsistema el uso de fachadas ayuda a organizar un sistema en capas, ayuda a controlar o eliminar las dependencias complejas o circulares entre objetos y permite hacer cambios en los componentes de un subsistema sin afectar a los clientes.
• En general facilita enormemente el desarrollo independiente de clientes y subsistemas y tiene consecuencias muy importantes sobre la reusabilidad de los subsistemas, objetivo principal perseguido por todos los patrones de diseño.
• En grandes sistemas de software es muy importante la aportación del patrón a la  reducción de dependencias de compilación y a la portabilidad.

Algunas consecuencias que podrían parecer “desventajas” no son tales:

• Oculta parte de la funcionalidad de un subsistema. Esto es cierto para clientes que se decanten por la facilidad de uso de la fachada, pero nada les impide mirar más allá de la misma para aprovechar toda la generalidad del subsistema.
• Introduce un nivel de indirección adicional que podría afectar al rendimiento de la aplicación.

Requisitos de Implementación 

• Soporte para creación de interfaces
• Soporte para almacenar sesión temporal del cliente
• Comunicación remota con objetos (en el caso de agrupar servicios a clientes remotos)