sábado, 9 de febrero de 2013

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.

1 comentario:

  1. ¡Excelente explicación! sencilla y clara. Mi agradecimiento por su publicación.

    ResponderEliminar