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)
No hay comentarios:
Publicar un comentario