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.
- 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.
¡Excelente explicación! sencilla y clara. Mi agradecimiento por su publicación.
ResponderEliminar