2010-06-04 22 views
7

Desidero implementare un progetto in Java in cui dispongo di più origini di eventi (thread). Tale origine di eventi svolge un'attività specifica e ha dovuto notificare l'esclusivo Gestore di eventi (Classe) e questo deve eseguire altre attività in base alle notifiche delle fonti di eventi.Java, Motivo di progettazione: più origini di eventi e un gestore di eventi One

La mia domanda è: come implementare questo desiqn nel modo appropriato in Java? C'è un motivo di progettazione simile a questo disegno?

Grazie in anticipo :).

+0

Lol @ risposte: 3 modelli diversi !!! – Pindatjuh

+0

Puoi darmene uno ?? – Zakaria

+0

buona domanda avrei appena usato un blocco sincronizzato in un metodo di callback della classe gestore – fasseg

risposta

3

Penso che stiate cercando il modello Observer. Java ha alcune interfacce standard (java.util.Observer, java.util.Observable), sebbene queste non siano specifiche per tipo; quindi potresti considerarlo tuo se il dominio lo richiede.

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

Grazie Justin per la tua risposta. Ho provato questa soluzione, ma il problema era nei thread (che sono considerati come osservabili) perché i miei thread si estendono già da un'altra classe e, se si desidera utilizzare Observable, è necessario estenderlo e, come sapete, non è consentita l'ereditarietà multipla in Java. Hai qualche suggerimento? – Zakaria

+0

La tua discussione può includere un Osservabile o la tua classe base può essere estesa. L'uso di runnable (invece di estendere Thread) è preferito per questo, tra le altre ragioni. – Justin

+0

Grazie! Capisco la tua idea e l'ho implementata. Ma davvero non capisco il tuo esempio di codice: Per prima cosa non possiamo implementare Osservabile dobbiamo estenderlo. Probabilmente vuoi dire Observer. Se questo è corretto, l'esempio del codice va bene. – Zakaria

0

Suona come un modello di attore per me. Ogni thread funge da attore, realizzando un singolo compito. Il risultato è impostato su una coda (sì) per essere elaborato dal prossimo attore.

Non ho esperienza con i framework di java actor, però. Consulta Google per questo.

+0

Grazie Arjan Molenaar per il tuo responso. Go go for Actor framework in Java, puoi darmi ulteriori spiegazioni? – Zakaria

0

In GWT, questo è chiamato event bus. O GWT. HandlerManager o GWTx. PropertyChangeSupport sono le implementazioni consigliate da Google. Quest'ultimo è disponibile in J2SE dal 1.4.2

+0

Grazie per la risposta. Posso usare queste implementazioni per eventi non GUI ?? – Zakaria

+0

Un HandlerManager è solo una coda di osservatori. Quando un evento viene attivato su HandlerManager, il gestore controlla ogni osservatore se può rispondere all'evento. se è possibile, allora l'overserver verrà chiamato con gli argomenti appropriati e così via. –

+0

Sì, Zakaria, java.beans.PropertyChangeSupport può essere utilizzato per eventi non GUI. – Glenn

0

Forse non capisco la tua domanda, ma penso che non sia necessario alcun modello di progettazione, ma qualcosa dal pacchetto java.util.concurrent.

A ThreadPoolExecutor?

0

Il pattern osservabile non ha valore sulla filettatura. In EventThread pattern il listener può indicare in quale thread e quando viene gestito l'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()); 
Problemi correlati