Callback/Command vs EventListener/Observer Pattern

Question

I'm trying to design an async framework and wanted to know what people think are the pros/cons of the callback pattern vs the observer pattern.

Callback pattern:

//example callback
public interface Callback{
    public void notify(MethodResult result);
}

//example method
public class Worker{
  public void doAsyncWork(Callback callback){
     //do work
     callback.notify(result);
  }
}

//example observer pattern
public interface EventListener{
   public void notify(MethodResult result);

}

public class Worker{
  private EventListener listener;
  public registerEventListener(EventListener listener){
   this.listener=listener;
  }
  public void doAsyncWork(){
     //do work
     listener.notify(result);
  }
}

I'm working with a framework which seems to use both of these patterns. The EventListener pattern is not the typical pattern as it doesn't have a list of listeners. This can easily be implemented though by creating a CompositeListener which has its own semantics on the priority of listeners and how to handle the distribution of events to each listener e.g. spawning a new thread for each listener vs serial notifications. (I actually think this is a good idea as its a good separation of concerns and is an improvement on the standard observer/listener pattern).

Any thoughts on when you should use each?

Thxs.

Answer 1

Command, callback and observer patterns have different semantics:

• callback - notifies a single caller that some operation finished with some result
• observer - notifies zero to n interested parties that some event (for example a finished operation) happened
• command - encapsulates a operation call in an object thus making it transferable over a wire or persist-able

In your example you could combine both callback and observer patterns to achieve greater API flexibility:

1. Use the callback pattern to trigger operations and notify the caller asynchronously that the triggered operation finished.
2. Use the event/observer pattern to give some other components (that did not trigger the operation) the chance to be notified when an operation finishes.