martes, 19 de mayo de 2009

Facade


Nombre del patrón
Facade o Fachada

Clasificación del patrón
Estructural

Intención
Proporciona una interfaz unificada a un conjunto de interfaces en un subsistema. Define una interfaz de alto nivel que hace al subsistema más fácil de usar.

Motivación
Estructurar un sistema en subsistemas ayuda a reducir la complejidad. Un objetivo común en el diseño es minimizar la comunicación y dependencias entre los subsistemas. Una forma de lograr este objetivo es introducir un objeto fachada que proporciona una interfaz única y simplificada.

Aplicabilidad
Usamos el patrón Facade cuando:

  • Se quiere proveer una interfaz simple a un subsistema complejo.
  • Hay muchas dependencias entre los clientes y las clases del subsistema.
  • Se quiere crear una capa sobre el subsistema que defina un punto de entrada para cada nivel de subsistema.

Estructura

Participantes
Facade

  • Sabe que clases del subsistema son responsables de un requerimiento u solicitud.
  • Delega los requerimientos del cliente a los objetos apropiados del subsistema.

Subsystem clases

  • Implementa funcionalidades del subsistema.
  • Maneja el trabajo asignado por el objeto Facade.
  • No tiene conocimiento de la fachada, no mantiene las referencias a esta.

Colaboraciones

  • Los clientes se comunican con el subsistema mediante en envió de peticiones a la fachada, que las reenvía al subsistema apropiado. A pesar que los objetos del subsistema realizan en realidad el trabajo, la fachada tiene que hace su propio trabajo de traducir su interfaz a las interfaces del subsistema.
  • Los clientes que usan la fachada no tiene acceso a los objetos del subsistema directamente.

Consecuencias
El patrón Facade ofrece los siguientes beneficios:

  • Aísla a los clientes de los componentes del subsistema, lo cual reduce el número de componentes que el cliente utiliza.
  • Promueve un acoplamiento débil entre el subsistema y los clientes.
  • No impide que las aplicaciones utilicen las clases del subsistema.

Implementación
Consideramos los siguientes aspectos en la aplicación de Facade.

  • La reducción de acoplamiento cliente-subsistema. El acoplamiento entre los clientes y el subsistema puede reducirse aun mas al hacer una clase abstracta Fachada con subclases concretas para las distintas aplicaciones de un subsistema.
  • Subsistemas de clases públicos o privados. Un subsistema es análogo a una clase en la que ambos tiene interfaces y ambos encapsulan algo, una clase encapsula el estado las operaciones, mientras que in subsistema encapsula clases. Y del mismo modo que es útil pensar en partes públicas y privadas en la interfaz de una clase, podemos pensar en los elementos públicos y privados de la interfaz de un subsistema.
    La interfaz publica de un subsistemas se compone de las clases que todos los clientes pueden acceder, la interfaz privada es sólo para extender subsistemas.

Usos Conocidos
El patrón Facade es común en numerosas librerías de software, tanto comerciales como libres y su utilización está más o menos bastante generalizada en gran parte de las librerías software.
Algunos ejemplos concretos son las clases Font y Graphics de las librerías estándar de Java que proporcionan la funcionalidad básica para manipulación de fuentes y gráficos aislando al usuario, en las operaciones más comunes, de la complejidad subyacente. Otros ejemplos incluyen determinados interfaces de librerías GIS o librerías matemáticas.

Patrones relacionados

  • Abstract Factory puede ser usado con Facade para proporcionar una interfaz para crear objetos del subsistema en una forma de subsistema independiente.
  • Mediator Es similar a Facade, ambos abstraen la funcionalidad de las clases, Mediator abstrae arbitrariamente la comunicación entre los objetos colegas, los objetos colegas están enterados de esto y se comunican con el Mediator y no directamente entre ellos. El patrón Facade solamente abstrae la interfaz a los objetos del subsistema para facilitar su uso, los objetos del subsistema no saben de la existencia del patrón Facade, además este no define nuevas funcionalidades.
  • Por lo general sólo un objeto fachada es obligatoria. Así los objetos Facade son Singleton.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.slideshare.net/jlrvpuma/facade-design-pattern-gof?src=related_normal&rel=1380529
http://www.stackframe.net/es/content/11-2008/patrones-de-diseno-facade-pattern

1 comentario:

  1. referencias:
    Alan Shalloway, J. R. (2001). Design Patterns Explained: A New Perspective on Object-Oriented Design. (A.-W. Professional, Ed.)

    ResponderEliminar