简体   繁体   English

观察者模式 vs 事件总线消息方法

[英]Observer pattern vs Event Bus message approach

I've been looking at MVC implementations and Event-bus closely.我一直在密切关注 MVC 实现和事件总线。

Why not use Event-bus instead of Observer Pattern to implement a MVC application?为什么不使用 Event-bus 而不是 Observer Pattern 来实现 MVC 应用程序?

For example, lets say I have two classes Model and View , In typical observer pattern it would be:例如,假设我有两个类ModelView ,在典型的观察者模式中,它将是:

public class Model implements Subject { ... }

public class View implements Observer { ... }

Instead, what is the benefit/drawback of an approach using green robot event bus or any other Event-bus?相反,使用绿色机器人事件总线或任何其他事件总线的方法有什么好处/缺点?

It would be something like:它会是这样的:

public class Model {
   private int field = 0; 

   void someFunctionNowTriggerStateChange() {
     this.field = field + 1;
     ...EventBus.getDefault().post(this); //pass itself as the event
   }
}

public class View {

  @Subscribe onModelUpdated(Model model) {
    updateTextLabel(model);
    //other model updates
  }   
}

What are the issues (if any) of using the EventBus to implement MVC vs typical Observer?与典型的观察者相比,使用 EventBus 实现 MVC 有哪些问题(如果有)?

EventBus implements publisher subscriber pattern, EventBus 实现了发布者订阅者模式,

EventBus is an open-source library for Android and Java using the publisher/subscriber pattern for loose coupling. EventBus 是 Android 和 Java 的开源库,使用发布者/订阅者模式进行松散耦合。

Thedifference from observer pattern is that publisher is loosely coupled from subscribers 与观察者模式区别在于发布者订阅者是松耦合的

publisher and subscriber don't know about the existence of one another.发布者和订阅者不知道彼此的存在。 There is a third component, called broker or message broker or event bus, which is known by both the publisher and subscriber, which filters all incoming messages and distributes them accordingly.还有第三个组件,称为代理或消息代理或事件总线,发布者和订阅者都知道它,它过滤所有传入的消息并相应地分发它们。 In other words, pub-sub is a pattern used to communicate messages between different system components without these components knowing anything about each other's identity.换句话说,pub-sub 是一种用于在不同系统组件之间传递消息的模式,而这些组件并不知道彼此的身份。

One advantage is that Publisher/Subscriber pattern can be normally/easier to be implemented in an asynchronous way because having a third component, broker, assist to implement asynchronous behavior, because execution becomes loosely coupled一个优点是发布者/订阅者模式可以正常/更容易地以异步方式实现,因为有第三个组件,代理,帮助实现异步行为,因为执行变得松散耦合

Another advantage, because Publisher/Subscriber pattern is loosely coupled, it will be more intuitive/easier to implement also multiple subscribers另一个优点,因为发布者/订阅者模式是松散耦合的,实现多个订阅者会更直观/更容易

Observer pattern is mostly implemented in a synchronous way, ie the Subject calls the appropriate method of all its observers when some event occurs.观察者模式大多以同步方式实现,即当某个事件发生时,Subject 调用其所有观察者的适当方法。 The Publisher/Subscriber pattern is mostly implemented in an asynchronous way (using message queue).发布者/订阅者模式主要以异步方式实现(使用消息队列)。

If you don't need (and won't need) such broker, you are safe to use Observer pattern, which will make your code smaller and simpler如果你不需要(也不会需要)这样的代理,你可以安全地使用观察者模式,这将使你的代码更小更简单

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM