patrones de diseño: fachada - observador fachada

Patrones de Diseño: Fachada - Observador

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.

FACHADAFACHADA


MOTIVACION: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.

FACHADAFACHADA


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

FACHADAFACHADA


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.

FACHADAFACHADA


ESTRUCTURA

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

FACHADAFACHADA


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.

ESTRUCTURA

1. Estática1. Estática

FACHADAFACHADA



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.

FACHADAFACHADA



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.

FACHADAFACHADA


2. Dinámica2. Dinámica

Diagrama de Secuencia – Patrón en funcionamiento

FACHADAFACHADA

Los clientes interaccionan con el subsistema enviando mensajes al objeto Fachada, que los remite a los objetos del subsistema.


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.

2. Dinámica2. Dinámica

FACHADAFACHADA


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 unsubsistema.

FACHADAFACHADA


IMPLEMENTACIONIMPLEMENTACION

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.

FACHADAFACHADA


Fachada dependiendo de clases abstractas

FACHADAFACHADA



FACHADAFACHADA

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(); }}

IMPLEMENTACION EN JAVAIMPLEMENTACION EN JAVA


FACHADAFACHADA

STRINGTRANSFORMED.JAVA

public class StringTransformer { public static String transformToUpper(String s)

{ return s.toUpperCase(); }

public static String transformToLower(String s) { return s.toLowerCase();

} }

IMPLEMENTACION EN JAVAIMPLEMENTACION EN JAVA


FACHADAFACHADAOUTFACADE.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.newline(); RegularScreen.print(Decoration.getDecoration()); RegularScreen.newline(); s = StringTransformer.transformToLower(s); RegularScreen.print(s); RegularScreen.newline(); RegularScreen.print(Decoration.getDecoration()); RegularScreen.newline(); } }


FACHADAFACHADA

MAIN.JAVApublic 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"); }}


FACHADAFACHADA

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

}}


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

FACHADAFACHADA

Estructura del patrón Factoría Abstracta en el contexto de uso junto con la fachada


PATRONES RELACIONADOS

AdaptadorUna 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.

SingletonNormalmente 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.

FACHADAFACHADA

OBSERVADOROBSERVADOR


INTENCIÓNINTENCIÓNDefinir una dependencia 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean notificados y se actualicen automáticamente

MOTIVACIONMOTIVACIONEn 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).



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 :



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.



ESTRUCTURAESTRUCTURA



PARTICIPANTESPARTICIPANTES

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.



ESTRUCTURAESTRUCTURA



COLABORACIONESCOLABORACIONES

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




OBSERVADOROBSERVADORDIAGRAMA DE DIAGRAMA DE INTERACCIONINTERACCION

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..

APLICABILIDADAPLICABILIDAD



CARACTERISTICACARACTERISTICASS

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.



CONSECUENCIASCONSECUENCIAS

VentajasVentajasPermite reutilizar sujetos y observadores por separado así como añadir nuevos observadores sin modificar el sujeto o los otros observadoresEl acoplamiento abstracto entre el sujeto y el observador ayuda a la división en niveles del sistema

DesventajasDesventajasPuede 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



IMPLEMENTACIOIMPLEMENTACIONN 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



APLICACIONESAPLICACIONES

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.



EJERCICIOSEJERCICIOS

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?




INTERFAZ OBSERVERINTERFAZ OBSERVERAvisa a los observadores de que se ha producido un Avisa a los observadores de que se ha producido un

cambiocambioabstract interface Observerabstract interface Observer {{

public void sendNotify(String s);public void sendNotify(String s);}} INTERFAZ SUBJECTINTERFAZ SUBJECTAvisa al sujeto de los observadores interesadosAvisa al sujeto de los observadores interesadosabstract interface Subjectabstract interface Subject {{

public void registerInterest(Observer obs);public void registerInterest(Observer obs);}}

CLASE MiBoton (Sujeto Concreto)CLASE MiBoton (Sujeto Concreto)

public class MiBoton extends JButton public class MiBoton extends JButton implements Subject implements Subject

{{Random r = new Random();Random r = new Random();ArrayList observadores = new ArrayList();ArrayList observadores = new ArrayList();Color c = Color.red;Color c = Color.red;public MiBoton(String nombre)public MiBoton(String nombre) {{

super(nombre);super(nombre);setForeground(c);setForeground(c);

}}



public void registerInterest(Observer obspublic void registerInterest(Observer obs) ) {{

observadores.add(obs);observadores.add(obs);}}

public void cambiaColor() public void cambiaColor() {{

c = new c = new Color(r.nextInt(255),r.nextInt(255),r.nextInt(255))Color(r.nextInt(255),r.nextInt(255),r.nextInt(255));;

for (int i=0;i<observadores.size();i++) for (int i=0;i<observadores.size();i++) {{((Observer)observadores.get(i)).sendNotify ((Observer)observadores.get(i)).sendNotify ("cambio de color");("cambio de color");}}

}}


public Color getColor()public Color getColor()

{{

return c;return c;

}}

public void registerInterest(Observer obs)public void registerInterest(Observer obs)

{{

observadores.add(obs);observadores.add(obs);

}}

}}


CLASE MiPanel CLASE MiPanel

Implementa la Interfaz OBSERVERImplementa la Interfaz OBSERVER

class MiPanel extends JPanel implements Observerclass MiPanel extends JPanel implements Observer

{{

MiBoton b = null;MiBoton b = null;

public MiPanel(MiBoton b)public MiPanel(MiBoton b)

{{

super();super();

this.b = b;this.b = b;

b.registerInterest(this);b.registerInterest(this);

}}


public void sendNotify(String mensaje) public void sendNotify(String mensaje)

**Método implementado por la interfaz OBSERVER ****Método implementado por la interfaz OBSERVER **

{{

setBackground(b.getColor());setBackground(b.getColor());

}}

}}


CLASE MiFrameCLASE MiFrameImplementa la Interfaz OBSERVERImplementa la Interfaz OBSERVER public class MiFrame extends JFrame public class MiFrame extends JFrame {{

public MiFrame()public MiFrame() {{

final MiBoton b = new MiBoton("Pulsame ya");final MiBoton b = new MiBoton("Pulsame ya");b.addActionListener(new ActionListener() b.addActionListener(new ActionListener() {{

public void public void actionPerformed(ActionEvent e) actionPerformed(ActionEvent e)

{{b.cambiaColor();b.cambiaColor();

}}});});


this.getContentPane().add(b);this.getContentPane().add(b);this.getContentPane().add(new this.getContentPane().add(new MiPanel(b),BorderLayout.NORTH);MiPanel(b),BorderLayout.NORTH);

this.getContentPane().add(new this.getContentPane().add(new MiPanel(b),BorderLayout.SOUTH);MiPanel(b),BorderLayout.SOUTH);

this.getContentPane().add(new this.getContentPane().add(new MiPanel(b),BorderLayout.EAST);MiPanel(b),BorderLayout.EAST);

this.getContentPane().add(new this.getContentPane().add(new MiPanel(b),BorderLayout.WEST);MiPanel(b),BorderLayout.WEST);

setSize(500,400);setSize(500,400);setVisible(true);setVisible(true);setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);;

}}


CLASE PRINCIPALCLASE PRINCIPAL

public static void main(String[ ] args) public static void main(String[ ] args)

{{

new B( );new B( );

}}

}}

RESULTADORESULTADO

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?¿QUÉ PATRON USO?

Considerar los problemas de diseñoConsiderar los problemas de diseño Seleccionar los patrones que los resuelvanSeleccionar los patrones que los resuelvan Observar la intención de un patrónObservar la intención de un patrón Escoger los más cercanos al problemaEscoger los más cercanos al problema Estudiar como se interrelacionan los patronesEstudiar como se interrelacionan los patrones Quizás haya que usar más de unoQuizás haya que usar más de uno Estudiar los PDs de propósito similarEstudiar los PDs de propósito similar Comparar posibles solucionesComparar posibles soluciones Estudiar posibles causas de rediseñoEstudiar posibles causas de rediseño Tener en cuenta las que evitan los patronesTener en cuenta las que evitan los patrones Considerar la variabilidad en el diseñoConsiderar la variabilidad en el diseño

patrones de diseño: fachada - observador fachada

Documents