FACHADA

FACHADA INTENCION El patrón fachada proporciona una interfaz de alto nivel para un subsistema, que oculta las interfaces de bajo nivel de las clases que lo implementan. Hacer el subsistema más fácil de usar Desacoplar a los clientes de las clases del subsistema.

FACHADA MOTIVACION: Problema: Un cliente trata de utilizar los servicios ofrecidos por un subsistema actuando directamente sobre las interfaces de las clases que lo implementan, esto genera fuertes dependencias hacia muchas de estas interfaces de bajo nivel . Solución: Aislar a los clientes de las interfaces de bajo nivel del subsistema colocando entre ambos una clase denominada genéricamente “fachada” del subsistema.

FACHADA Clientes utilizando un subsistema antes y después de introducir la fachada

FACHADA APLICACIONES Necesidad de dotar de una interfaz sencilla y usable a un subsistema complejo. Se tiene un subsistema que ofrece una funcionalidad muy rica y compleja, y un conjunto significativo de clientes que solo necesitan usar una parte reducida de la misma. Sólo los clientes que necesiten detalles de más bajo nivel accederán a las clases detrás de la fachada Necesidad de reducir la dependencia entre las clases que implementan un subsistema y sus clientes.

FACHADA ESTRUCTURA Estática: Descripción de los participantes y sus responsabilidades.

FACHADA ESTRUCTURA 1. Estática Clases del Subsistema: Implementan la funcionalidad del subsistema. Tienen un estrecho conocimiento las unas de las otras y colaboran para llevar a cabo el trabajo asignado por la Fachada. No conocen de la existencia del objeto Fachada.

FACHADA 1. Estática Fachada: Conoce la distribución de responsabilidades entre las clases del subsistema. Mantiene referencias hacia muchos de los objetos del subsistema y delega en ellos para llevar a cabo su trabajo. No tiene conocimiento a cerca de los clientes.

FACHADA 1. Estática Clientes Mantienen una referencia al objeto Fachada. Envían sus mensajes al mismo para acceder a la funcionalidad del subsistema. En general no mantienen referencias a los objetos internos del subsistema, pero no se les impide adquirirlas si lo necesitan.

Diagrama de Secuencia – Patrón en funcionamiento FACHADA 2. Dinámica Diagrama de Secuencia – Patrón en funcionamiento Los clientes interaccionan con el subsistema enviando mensajes al objeto Fachada, que los remite a los objetos del subsistema.

FACHADA 2. Dinámica El objeto Fachada realiza solamente tareas de traducción. El objeto Fachada reacciona generando una secuencia de mensajes que pondrá a los objetos internos en colaboración. Los clientes no accederán a los objetos internos directamente.

FACHADA CONSECUENCIAS Desde el punto de vista de los Clientes, la fachada los aísla del subsistema minimizando el número de objetos con los que tiene que tratar para obtener un servicio. Desde el punto de vista del subsistema el uso de fachadas ayuda a organizar un sistema en capas, ayuda a controlar o eliminar dependencias entre objetos y permite hacer cambios en los componentes de un subsistema sin afectar a los clientes. Oculta parte de la funcionalidad de un subsistema.

FACHADA IMPLEMENTACION Se puede reducir más el acoplamiento entre los clientes y el subsistema haciendo que la fachada sea una clase abstracta. Se puede conseguir que la implementación sea independiente del subsistema configurando la fachada con diferentes objetos del subsistema.

FACHADA IMPLEMENTACION Fachada dependiendo de clases abstractas

FACHADA IMPLEMENTACION EN JAVA public class Decoration DECORATION.JAVA public class Decoration { public static String getDecoration() { return "******************"; } } REGULARSCREEM.JAVA public class RegularScreen { public static void print(String s) { System.out.print(s); } public static void newline() { System.out.println(); } }

FACHADA IMPLEMENTACION EN JAVA STRINGTRANSFORMED.JAVA public class StringTransformer { public static String transformToUpper(String s) return s.toUpperCase(); } public static String transformToLower(String s) return s.toLowerCase();

FACHADA OUTFACADE.JAVA public class OutputFacade { public void printNormal(String s) { RegularScreen.print(s); RegularScreen.newline(); } public void printFancy(String s) { RegularScreen.print(Decoration.getDecoration()); RegularScreen.newline(); s = StringTransformer.transformToUpper(s); RegularScreen.print(s); RegularScreen.print(Decoration.getDecoration()); s = StringTransformer.transformToLower(s); } FACHADA

FACHADA public class Main { public static void main(String[] args) MAIN.JAVA public class Main { public static void main(String[] args) OutputFacade facade = new OutputFacade(); System.out.println("Testing Facade..."); facade.printNormal("Printing normally works FINE."); facade.printFancy("This is the test for the FANCY output"); }

FACHADA RESULTADO Testing Facade... Printing normally works FINE. ****************** THIS IS THE TEST FOR THE FANCY OUTPUT this is the test for the fancy output } }

FACHADA PATRONES RELACIONADOS Factoría Abstracta: Se puede componer la fachada con una factoría de objetos del subsistema para que cree (y maneje) los objetos a través de una interfaz abstracta, de una forma independiente del subsistema Estructura del patrón Factoría Abstracta en el contexto de uso junto con la fachada

FACHADA PATRONES RELACIONADOS Adaptador Una Fachada y un Adaptador son similares en cuanto que proporcionan una interfaz que se expresa en términos de las interfaces de otras clases. Sin embargo en el patrón Adaptador el énfasis está en adaptar interfaces incompatibles mientras que el patrón Fachada lo pone en simplificar un conjunto de interfaces. Singleton Normalmente todos los clientes se comunicarán con el subsistema a través de una misma instancia de la Fachada. Por tanto las fachadas son a menudo Singletons.

Patrones de Diseño: Fachada - Observador

Patrones de Diseño: Fachada - Observador INTENCIÓN Definir una dependencia 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean notificados y se actualicen automáticamente MOTIVACION En un toolkit de GUI, separar los objetos de presentación (vistas) de los objetos de datos, de forma que se puedan tener varias vistas sincronizadas de los mismos datos (editor-suscriptor).

Patrones de Diseño: Fachada - Observador En la actualidad es común encontrarnos con aplicaciones que muestran simultáneamente un conjunto de datos de múltiples formas diferentes en el mismo interfaz ( por ejemplo en forma de árbol, tabla, lista, ... ). El patrón Observer asume que el objeto que contiene los datos es independiente de los objetos que muestran los datos de manera que son estos objetos los que “observan” los cambios en dichos datos :

Patrones de Diseño: Fachada - Observador

Patrones de Diseño: Fachada - Observador Al implementar el patrón Observer el objeto que posee los datos se conoce como sujeto mientras que cada una de las vistas se conocen como observadores. Cada uno de estos observadores, registra su interés en los datos llamando a un método público del sujeto. Entonces, cuando estos datos cambian, el sujeto llama a un método conocido de la interfaz de los observadores de modo que estos reciben el mensaje de que los datos han cambiado y actualizan la vista.

Patrones de Diseño: Fachada - Observador ESTRUCTURA

OBSERVADOR PARTICIPANTES Patrones de Diseño: Fachada - Observador OBSERVADOR PARTICIPANTES Sujeto: Mantiene una lista de observadores y proporciona una interfaz para que se suscriban. Observador: Define una interfaz para actualizar los objetos que deban ser notificados de cambios en el sujeto SujetoConcreto: Envía una notificación a sus observadores cuando cambia su estado. ObservadorConcreto: Mantiene una referencia a un sujeto (SujetoConcreto), almacena parte del estado del sujeto e implementa la interfaz de actualización de Observador para mantener su estado consistente con el del sujeto.

Patrones de Diseño: Fachada - Observador ESTRUCTURA

OBSERVADOR COLABORACIONES Patrones de Diseño: Fachada - Observador OBSERVADOR COLABORACIONES SujetoConcreto notifica a sus observadores cuando ocurre un cambio. Cuando se le informa del cambio, los observadores pueden solicitar información al sujeto para actualizar su estado

DIAGRAMA DE INTERACCION Patrones de Diseño: Fachada - Observador OBSERVADOR DIAGRAMA DE INTERACCION

OBSERVADOR APLICABILIDAD Patrones de Diseño: Fachada - Observador OBSERVADOR APLICABILIDAD Cuando un cambio en un objeto requiera cambiar otros y no se sepa cuantos objetos necesitan cambiar Cuando un objeto deba ser capaz de notificar a otros sin conocer su clase concreta, evitando así acoplarlos Cuando el número de oyentes puede variar durante el ciclo de vida del objeto. Cuando el bajo acoplamiento es un requerimiento básico del diseño..

OBSERVADOR CARACTERISTICAS Patrones de Diseño: Fachada - Observador OBSERVADOR CARACTERISTICAS El objeto observado no necesita saber nada acerca de los observadores. Son los observadores quienes deben registrarse como 'oyentes' para poder recibir eventos. Esto permite el desarrollo de aplicaciones con componentes poco acoplados. el bajo acoplamiento se considera una ventaja ya que simplifica la posterior reutilización de componentes. Los oyentes reciben notificación de todos los eventos generados en los objetos observados. Pueden registrarse en cualquier momento durante el ciclo de vida del componente.

OBSERVADOR CONSECUENCIAS Ventajas Patrones de Diseño: Fachada - Observador OBSERVADOR CONSECUENCIAS Ventajas Permite reutilizar sujetos y observadores por separado así como añadir nuevos observadores sin modificar el sujeto o los otros observadores El acoplamiento abstracto entre el sujeto y el observador ayuda a la división en niveles del sistema Desventajas Puede que cambios pequeños para unos observadores representen grandes cambios en otros, que además pueden tener problemas para detectar qué es lo que ha cambiado

OBSERVADOR IMPLEMENTACION Patrones de Diseño: Fachada - Observador OBSERVADOR IMPLEMENTACION El sujeto puede pasarse a sí mismo como parámetro en la notificación de los cambios Hay dos opciones según quien dispare la actualización: Que las operaciones de cambio de estado del sujeto llamen automáticamente a Notificar Que sean los observadores los que llamen a Notificar. Las actualizaciones serán más eficientes, pero puede que algún observador se olvide de hacerlo Cuando el sujeto es destruido los observadores deben ser destruidos o notificados de su destrucción Hay que asegurarse de que el estado del sujeto es coherente antes de notificar a los observadores

OBSERVADOR APLICACIONES Patrones de Diseño: Fachada - Observador OBSERVADOR APLICACIONES En Swing los objetos JList, JTable y JTree actúan como observadores de un modelo de datos De hecho todos los objetos que deriven de JComponent pueden realizar esta separación entre vista y datos, esto se conoce como arquitectura MVC (Modelo-Vista-Controlador), donde los datos son representados por el modelo y la vista por el componente visual. En este caso el controlador es la comunicación entre el modelo y la vista. Por último podemos usar las clases Observer y Observable del paquete java.util.

OBSERVADOR EJERCICIOS Patrones de Diseño: Fachada - Observador OBSERVADOR EJERCICIOS Describe cómo el Modelo de Delegación de Eventos de Java es una forma especializada del patrón Observer. ¿Cómo es posible implementar el patrón Observer de modo que cada observador pueda indicar que sólo está interesado en ciertos cambios y sólo reciba notificación de ellos?

IMPLEMENTACION INTERFAZ OBSERVER Avisa a los observadores de que se ha producido un cambio abstract interface Observer { public void sendNotify(String s); } INTERFAZ SUBJECT Avisa al sujeto de los observadores interesados abstract interface Subject public void registerInterest(Observer obs);

IMPLEMENTACION CLASE MiBoton (Sujeto Concreto) public class MiBoton extends JButton implements Subject { Random r = new Random(); ArrayList observadores = new ArrayList(); Color c = Color.red; public MiBoton(String nombre) super(nombre); setForeground(c); }

IMPLEMENTACION public void registerInterest(Observer obs) { observadores.add(obs); } public void cambiaColor() c = new Color(r.nextInt(255),r.nextInt(255),r.nextInt(255)); for (int i=0;i<observadores.size();i++) ((Observer)observadores.get(i)).sendNotify ("cambio de color");

IMPLEMENTACION public Color getColor() { return c; } public void registerInterest(Observer obs) observadores.add(obs);

CLASE MiPanel IMPLEMENTACION Implementa la Interfaz OBSERVER class MiPanel extends JPanel implements Observer { MiBoton b = null; public MiPanel(MiBoton b) super(); this.b = b; b.registerInterest(this); }

IMPLEMENTACION public void sendNotify(String mensaje) **Método implementado por la interfaz OBSERVER ** { setBackground(b.getColor()); }

IMPLEMENTACION CLASE MiFrame Implementa la Interfaz OBSERVER public class MiFrame extends JFrame { public MiFrame() final MiBoton b = new MiBoton("Pulsame ya"); b.addActionListener(new ActionListener() public void actionPerformed(ActionEvent e) b.cambiaColor(); } });

IMPLEMENTACION this.getContentPane().add(b); this.getContentPane().add(new MiPanel(b),BorderLayout.NORTH); this.getContentPane().add(new MiPanel(b),BorderLayout.SOUTH); this.getContentPane().add(new MiPanel(b),BorderLayout.EAST); this.getContentPane().add(new MiPanel(b),BorderLayout.WEST); setSize(500,400); setVisible(true); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); }

IMPLEMENTACION CLASE PRINCIPAL public static void main(String[ ] args) { new B( ); }

RESULTADO Al pulsar el Botón, se va a generar un nuevo color aleatorio. El OBSERVER, al ser notificado del cambio, actualiza el color del fondo del JPanel.

¿QUÉ PATRON USO? Considerar los problemas de diseño Seleccionar los patrones que los resuelvan Observar la intención de un patrón Escoger los más cercanos al problema Estudiar como se interrelacionan los patrones Quizás haya que usar más de uno Estudiar los PDs de propósito similar Comparar posibles soluciones Estudiar posibles causas de rediseño Tener en cuenta las que evitan los patrones Considerar la variabilidad en el diseño