回拨/命令VS事件监听/ Observer模式 [英] Callback/Command vs EventListener/Observer Pattern

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

问题描述

我想设计一个异步的框架,想知道是什么人想的是利弊/回调模式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);
  }
}

我跟这似乎同时使用这两个模式的框架内工作。该事件监听模式不是因为它不具有听众的名单的典型模式。这可以很容易地通过创建这对听众的优先级以及如何处理事件的分布到每个听者如自己的语义CompositeListener虽然实施产卵每个听者VS系列通知一个新的线程。 (其实我觉得这是一个好主意,因为它的关注点分离效果好,是在标准观察者/监听器模式的改进版本)。

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。

推荐答案

这两种模式是伟大的,选择哪一个取决于你有什么要建立以及如何你的框架将被使用。

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:


  • 客户端启动异步任务,并忘掉它

  • 完成任务时,多个处理程序接收通知

然后观察模式是你的必然选择。当你正在做一个框架,你也应该考虑使用 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:


  • 启动异步任务

  • 做点什么完成时,它


  • 启动异步任务

  • 做点什么

  • 等待,直到它完成,并做一些

,那么你应该用简单的去回调

then you should go with simple Callback.

但是,为了实现更多的可用干净的API我建议你摆脱回调抽象和设计工作者code返回某种的未来

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

}

工人可以如下方式使用:

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

// some work here

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

未来可能是一个标准的 Java的未来。但我建议你使用<一个href=\"http://$c$c.google.com/p/guava-libraries/wiki/ListenableFutureExplained\"><$c$c>ListenableFuture从番石榴库。

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

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

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