Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.
El patrón fachada viene motivado por la necesidad de estructurar un entorno de programación y reducir su complejidad con la división en subsistemas, minimizando las comunicaciones y dependencias entre éstos.
Características
Ø 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.
Ventajas
Una de las ventajas de utilizar este patrón a la hora de controlar los permisos de los usuarios. Cada usuario tiene un rol (administrador, invitado, usuario registrado, etc.) y, para controlar los permisos de cada rol, lo único que hay que hacer es definir las operaciones de cada rol en distintos sesión beans de la capa de control y después, desde el deployment descriptor de los EJBs, mapear nuestros roles con dichos sesión beans. La autenticación se realiza en la capa de interfaz.
Desventajas.
Ø Oculta a los clientes los componentes del subsistema, reduciendo así el número de objetos con los que tratan los clientes y haciendo que el subsistema sea más fácil de usar.
Ø Promueve un débil acoplamiento entre el subsistema y sus clientes. Muchas veces los componentes de un subsistema sin que sus clientes se vean afectados, las fachadas ayudan a estructurar en capas un sistema y las dependencias entre los objetos. También pueden eliminar dependencias complejas o circulares. Esto puede ser una consecuencia importante cuando el cliente y el subsistema se implementan por separado.
En los grandes sistemas de software es vital reducir las dependencias de compilación. Queremos ahorrar tiempo minimizando la recopilación cuando cambien las clases del subsistema. Reducir las dependencias de compilación con fachada puede limitar la compilación necesaria para un pequeño cambio en un subsistema importante. Una fachada puede simplificar portar sistemas en otras plataformas ya que es menos probable que construir un subsistema requiera volver a construir todos los otros.Ø No impiden que las aplicaciones usen las clases del subsistema en caso de que sea necesario. De este modo se puede elegir entre la facilidad de uso y generalidad.
Participantes
Ø Client (EJBAccountFacadeDelegate)
Puede ser un Business Delegate u otro Session Facade
Ø SessionFacade (AccountFacadeEJB)
Normalmente, un Session Bean proporciona un interfaz sencillo al cliente, ocultando las relaciones entre numerosos objetos de negocioSession Facade (7)
Participantes (cont)
Ø Business Object (Account y AccountOperation)
Proporciona datos (Entity Bean o DAO) o un servicio (SessionBean)
A la hora de implementar una fachada deben tenerse en cuenta los siguientes aspectos:
Ø Reducción del acoplamiento cliente-subsistema. El acoplamiento entre clientes y el subsistema puede verse reducido todavía más haciendo que Fachada sea una clase abstracta con subclases concretas para diferentes implementaciones de un subsistema. De esa manera los clientes pueden comunicarse con el subsistema a través de la interfaz de una clase abstracta Fachada. Este acoplamiento abstracto evita que los clientes tengan que saber que implementación de un subsistema están usando.
Ø Clases del subsistema del subsistema públicas o privadas. Un subsistema se parece a una clase en que ambos tienen interfaces y los dos encapsulan algo – una clase encapsula estado y operaciones, mientras que un subsistema encapsula clases. Y del mismo modo resulta útil pensar en la interfaz pública y privada de una clase, también podemos pensar en la interfaz pública y privada de un subsistema.
Ø La interfaz pública de un subsistema consiste en una serie de clases a las que acceden todos los clientes; la interfaz privada es solo para quienes vayan a ampliar el subsistema. La clase fachada es parte de la interfaz pública, por supuesto pero no es la única. Otras clases del subsistema también suelen ser públicas.
No hay comentarios.:
Publicar un comentario