回调/命令 vs 事件监听器/观察者模式 [英] Callback/Command vs EventListener/Observer Pattern

查看:19
本文介绍了回调/命令 vs 事件监听器/观察者模式的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试设计一个异步框架,并想知道人们认为回调模式与观察者模式的优缺点.

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);
  }
}

我正在使用一个似乎同时使用这两种模式的框架.EventListener 模式不是典型的模式,因为它没有侦听器列表.这可以很容易地通过创建一个 CompositeListener 来实现,它在侦听器的优先级上有自己的语义,以及如何处理每个侦听器的事件分布,例如为每个侦听器与串行通知生成一个新线程.(我实际上认为这是一个好主意,因为它很好地分离了关注点,并且是对标准观察者/侦听者模式的改进).

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?

谢谢.

推荐答案

这两种模式都很棒,选择哪一种取决于您要构建什么以及如何使用您的框架.

Both patterns are great and which one to choose depends on what are you going to build and how your framework will be used.

如果您正在尝试构建某种具有以下典型工作流程的发布-订阅系统:

If you are trying to build some kind of publish-subscribe system with following typical flow of work:

  • 客户端启动异步任务并忘记它
  • 多个处理程序在任务完成时收到通知

那么 Observer 模式是您的自然选择.当你在做一个框架时,你还应该考虑使用 EventBus 模式来实现松耦合.

then Observer pattern is a natural choice for you. As you are doing a framework you should also consider using EventBus pattern to achieve loose coupling.

如果您只需要一个简单的异步执行和框架的典型使用流程是:

If you need nothing more than a simple asynchronous execution and a typical flow using of your framework is:

  • 启动异步任务
  • 完成后做一些事情

  • 启动异步任务
  • 做点什么
  • 等到它完成并做一些事情

那么你应该使用简单的Callback.

then you should go with simple Callback.

但为了实现更可用和更干净的 API,我建议您摆脱 Callback 抽象并设计您的工作代码以返回某种Future.

But in order to achieve more usable and clean API I'd recommend you to get rid of Callback abstraction and design your worker code to return a some kind of Future.

public interface Worker<T> {

    Future<T> doAsync();

}

Worker 可以通过以下方式使用:

And Worker can be used following way:

Future<Integer> future = worker.doAsync();

// some work here

Integer result = future.get(); // waits till async work is done

Future 可以是标准的 java未来.但我建议您使用番石榴库中的 ListenableFuture.

Future could be a standard java Future. But I'd suggest you to use ListenableFuture from guava library.

这篇关于回调/命令 vs 事件监听器/观察者模式的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆