2010-06-04 9 views
7

Quiero implementar un diseño en Java donde tengo múltiples orígenes de eventos (subprocesos). Dicha fuente de eventos logra una tarea específica y tuvo que notificar al único Manejador de eventos (Clase) y este debe realizar otras tareas de acuerdo con las notificaciones de fuentes de eventos.Java, patrón de diseño: múltiples orígenes de eventos y un controlador de eventos

Mi pregunta es: ¿cómo implementar este diseño de la manera adecuada en Java? ¿Hay un patrón de diseño similar a este diseño?

Gracias de antemano :).

+0

Lol @ respuestas: 3 patrones diferentes !!! – Pindatjuh

+0

¿Me puedes dar uno? – Zakaria

+0

buena pregunta que acababa de utilizar un bloque sincronizado en un método de devolución de llamada de la clase de controlador – fasseg

Respuesta

3

Creo que está buscando el patrón Observer. Java tiene algunas interfaces estándar (java.util.Observer, java.util.Observable), aunque estas no son específicas de tipo; por lo que podría considerar el suyo si el dominio parece requerirlo.

class MyThread implements Runnable { 
Observable observable; 

public MyThread(EventHandler observer) { 
    observable = new Observable(); 
    observable.addObserver(observer); 
} 

public void run() { 
    while (!done()) { 
    Object result = doStuff(); 
    observable.notifyObservers(result); 
    } 
} 
} 

// might have this be singleton 
class EventHandler implements Observer { 
public synchronized void update(Observable o, Object arg) { 
    accomplishOtherTask(); 
} 
} 
+0

Gracias Justin por su respuesta. Probé esta solución, pero el problema estaba en los subprocesos (que se consideran observables) porque mis hilos ya se extienden desde otra clase, y si desea usar Observable debe extenderse desde allí, y como sabe, no se permite la herencia múltiple en Java. ¿Tiene alguna sugerencia? – Zakaria

+0

Su hilo puede incluir un Observable o podría hacer que su clase base se extienda Observable. Usando Runnable (en lugar de extender Thread) es preferible para esto, entre otras razones. – Justin

+0

¡Gracias! Entiendo su Idea y la implementé. Pero realmente no entiendo tu código de muestra: Primero no podemos implementar Observable debemos extenderlo. Probablemente te refieres a Observer. Si esto es correcto, su muestra de código está bien. – Zakaria

0

Suena como un patrón de actor para mí. Cada hilo actúa como un actor, logrando una sola tarea. La salida está configurada en una cola (sí) para ser procesada por el siguiente actor.

No tengo experiencia con frameworks java actor, sin embargo. Consulte Google para eso.

+0

Gracias Arjan Molenaar por su respnse. Buscaré en Actor frameworks en Java, ¿me puede dar más explicaciones? – Zakaria

0

En GWT, esto se llama event bus. O bien GWT. HandlerManager o GWTx. PropertyChangeSupport son implementaciones recomendadas por Google. Este último está disponible en J2SE desde 1.4.2

+0

Gracias por su respuesta. ¿Puedo usar esas implementaciones para eventos que no sean GUI? – Zakaria

+0

Un HandlerManager es solo una cola de observadores. Cuando se dispara un evento en HandlerManager, el administrador verificará si cada observador puede responder al evento. si puede, entonces se llamará al servidor externo con los argumentos adecuados, y así sucesivamente. –

+0

Sí, Zakaria, java.beans.PropertyChangeSupport se puede utilizar para eventos que no sean GUI. – Glenn

0

Quizás no entiendo su pregunta, pero creo que no necesita ningún patrón de diseño, sino algo del paquete java.util.concurrent.

A ThreadPoolExecutor?

0

El patrón observable no tiene una opinión sobre el enhebrado. En EventThread pattern el oyente puede indicar en qué hilo y cuándo se maneja el evento.

public class MyObservableObject { 
    ... 
    void addListener(MyListener listener, Executor executor); 
} 
public interface MyListener { 
    void onEvent(Object sender, Object event); 
} 

// Example 
obj.addListener(myListener, CURRENT_THREAD); 
obj.addListener(myListener, myWorkQueue); 
obj.addListener(myListener, AWT_EDT); // or SWT_EDT 
obj.addListener(myListener, Executors.newSingleThreadScheduledExecutor()); 
Cuestiones relacionadas