11 Observer Implementación Al registrar un observer es posible asociarle el evento sobre el que quiere ser notificado.attach(Observer obs, Evento interes);
Cuando las relaciones de dependencia entre subjects y observers son complicadas encapsular la semántica de actualización en una clase ManejadorCambio (Mediador). En Smalltalk, las interfaces de las clases Subject y Observer se definen en la clase Object.
12 Observer en Java public class Observable { private boolean changed = false; private Vector obs; public Observable() { obs = new Vector(); } public synchronized void addObserver (Observer o) {..} public synchronized void deleteObserver (Observer o) {..} public void notifyObservers (Object arg) {..} protected synchronized void setChanged() {..} protected synchronized void clearChanged() {..} public synchronized boolean hasChanged() {.. }
13 Observer en Java
public interface Observer { void update (Observable o, Object arg); } Argumento pasado al método notifyObservers, puede indicar el tipo de cambio
14 Observer en Java Problema Que la clase que deseamos que actúe como Observable ya herede de otra clase: ¡En Java no hay herencia múltiple! Usar delegación Una clase ConcreteSubject contendrá a un objeto de una clase que heredará de Observable, y tendrá implementaciones “wrapper” de addObserver y deleteObserver. Se delega el comportamiento que necesita ConcreteSubject al objeto Observable que contiene. ¿Por qué una subclase de Observable?
15 Modelo de Eventos de Java 1.1 Java 1.1 introdujo un nuevo modelo de eventos basado en el patrón Observer. Objetos que pueden generar eventos son llamados fuentes de eventos (event sources). Objetos que desean ser notificados de eventos son llamados oyentes de eventos (event listeners). Una fuente juega el papel de ConcreteSubject y un listener juega el papel de ConcreteObserver. Los listeners deben registrarse en las fuentes. Un listener debe implementar una interfaz que proporciona los métodos que deben ser llamados por la fuente para notificar un evento.
17 Modelo de Eventos de Java 1.1 Es un modelo no orientado a eventos de componentes GUI. Hay 11 interfaces listener cada una apropiada para un diferente tipo de evento GUI: ActionListener, ItemListener, KeyListener, MouseListener, WindowListener, … En algunos casos la interfaz listener incluye más de un método: Java proporciona adaptadores
18 Modelo de Eventos de Java 1.1 public class CounterView extends Frame { private TextField tf = new TextField(10); private Counter counter; // referencia al modelo public CounterView(String title, Counter c) { super(title); counter = c; Panel tfPanel = new Panel(); … Button incButton = new Button("Increment"); incButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { counter.incCount(); tf.setText(counter.getCount() + ""); } } ); buttonPanel.add(incButton); …
19 Modelo de Eventos de Java 1.1 Si creamos dos instancias de CounterView para el mismo objeto contador, ¿Qué debemos hacer para que un cambio en el valor de contador en una de ellas afecte a la otra?
public class ObservableCounter extends Observable { private int count; public ObservableCounter(int count) { this.count = count; } public int getCount() { return count; } public void incCount() { count++; setChanged(); notifyObservers(); } … }
20 Modelo de Eventos de Java 1.1 public class ObservableCounterView extends Frame { private ObservableCounter counter; private TextField tf = new TextField(10); public ObservableCounterView(String title, ObservableCounter c) { super(title); counter = c; counter.addObserver(new Observer() { public void update(Observable src, Object obj) { if (src == counter) { tf.setText(((ObservableCounter)src).getCount() + "");} } } ); …
21 State (Estado) Propósito Permite a un objeto cambiar su comportamiento cuando cambia su estado. El objeto parece cambiar de clase. Motivación Una conexión TCP puede encontrarse en uno de varios estados, y dependiendo del estado responderá de un modo diferente a los mensajes de otros objetos para solicitudes tales como abrir, cerrar o establecer conexión.
22 Estado Motivación
23 Estado Estructura
24 Estado Aplicabilidad El comportamiento del objeto depende de su estado, y debe cambiar su comportamiento en tiempo de ejecución dependiendo de su estado. Las operaciones tienen grandes estructuras CASE que dependen del estado del objeto, que es representado por uno o más constantes de tipo enumerado.
25 Estado Consecuencias Coloca todo el comportamiento asociado a un particular estado en una clase. Subclases vs. Sentencias CASE. Ayuda a evitar estados inconsistentes Transiciones de estado son más explícitas. Incrementa el número de objetos Los objetos estado pueden ser Singleton.
26 Estado Implementación ¿Quién define las transiciones entre estados? Contexto o subclases estado. Una alternativa es definir tablas que representan la matriz de transiciones de estado: no es posible asociar acciones a los cambios de estado y más difícil de comprender. ¿Cuándo son creados los objetos estado? Pueden crearse cuando se necesiten o con antelación y que Contexto tenga una referencia a ellos.
27 Strategy/Policy (Estrategia) Propósito Define una familia de algoritmos, encapsula cada uno, y permite intercambiarlos. Permite variar los algoritmos de forma independiente a los clientes que los usan Motivación Existen muchos algoritmos para justificación de texto, ¿debe implementarlo el cliente que lo necesita?
28 Estrategia Motivación
29 Estrategia Estructura
30 Estrategia Aplicabilidad Configurar una clase con uno de varios comportamientos posibles. Se necesitan diferentes variantes de un algoritmo. Una clase define muchos comportamientos que aparecen como sentencias CASE en sus métodos.
| Página siguiente |