Facade Pattern

• Clasificación del patrón: estructural.
• Intención: proporcionar una interfaz unificada para un conjunto de interfaces de un sistema, y hace que los subsistemas sean mas facil de usar.
• También conocido como: ---
• Problema: Se utiliza este patrón cuando se necesita
• minimizar la comunicación y las dependencias entre subsistemas.
• proporcionar una interfaz sencilla para un subsistema complejo.
• eliminar dependencias entre clientes y clases de implementación, porque son demasiadas.
• dividir conjuntos de subsistemas en capas.

• Solución:  desacoplar el subsistema de los clientes y otros subsistemas, promoviendo así la independencia y la portabilidad.
• Estructura:

• Participantes: 
• Facade: Conoce cuales clases del subsistema son responsables de una peticion y delega las peticiones de los clientes en los objetos del subsistema.
• SubsystemClasses: implementan su propia funcionalidad y manejan el trabajo asignado por el objeto Facade. No saben de la existencia del Facade.
• Colaboraciones: 
• Client-Subsystem: Los clientes se comunican con el subsistema enviando peticiones a la fachada, quien los reenvía al subsistema apropiado. El Facade puede tener que hacer un trabajo propio para traducir su interfaz a las interfaces del subsistema.
• El objetivo es evitar que los clientes que utilizan la fachada puedan acceder a los subsistemas directamente (aunque podría implementarse un Facade opcional).
• Consecuencias: 
• el Facade protege a los clientes de los componentes del subsistema.
• permite modificar los componentes del subsistema sin afectar a sus clientes. 
• no impide que las aplicaciones utilicen los subsistemas si es necesario.
• Implementación: 
• Reducir el acoplamiento del cliente y los subsistemas. Para ello, el Facade podría ser una clase abstracta.
• Se puede elegir entre mantener públicos a los subsistemas, de modo que sean accesibles tanto directamente como mediante el Facade, o convertirlos en privados y sólo dejar que el Facade les delegue responsabilidades. Esto último podría provocar que el cliente termine utilizando muchas menos funciones o se encuentre limitado a las acciones que puede realizar sólo mediante el Facade.

• Motivación: 

• Patrones relacionados: 
• Un Facade es a menudo un Singleton.
• Se puede combinar e incluso puede reemplazar al AbstractFactory.
• Es muy parecido al Mediator Pattern, ya que ambos abstraen la funcionalidad de clases existentes. La diferencia se encuentra en que el Facade no define nueva funcionalidad y los subsistemas no conocen al Facade, como si lo puede hacer un Mediator.