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 anterior | Volver al principio del trabajo | Página siguiente  |