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

我一直在仔细研究MVC实现和事件总线

为什么不使用事件总线而不是观察者模式来实现MVC应用程序

例如，假设我有两个类Model和View，在典型的观察者模式中，它是：

public class Model implements Subject { ... }

public class View implements Observer { ... }

相反，使用事件总线或任何其他事件总线的方法的优点/缺点是什么

可能是这样的：

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

---

如果使用EventBus实现MVC与使用典型观察者相比有什么问题？

EventBus实现发布者-订阅者模式

EventBus是Android和Java的开源库，使用发布者/订阅者模式实现松耦合

问题是发布服务器与订阅服务器松散耦合

发布者和订阅者不知道彼此的存在。还有第三个组件，称为代理或消息代理或事件总线，发布者和订阅者都知道它，它过滤所有传入的消息并相应地分发它们。换句话说，pub-sub是一种用于在不同系统组件之间传递消息的模式，而这些组件不知道彼此的身份

一个优点是，发布者/订阅者模式通常可以/更容易以异步方式实现，因为有第三个组件broker辅助实现异步行为，因为执行变得松散耦合

另一个优点是，由于发布者/订阅者模式是松散耦合的，因此实现多个订阅者将更直观/更容易

观察者模式主要以同步方式实现，即当某个事件发生时，主体调用其所有观察者的适当方法。发布者/订阅者模式主要是使用消息队列以异步方式实现的

如果您不需要也不需要这样的代理，那么可以安全地使用Observer模式，这将使您的代码更小、更简单

---

@flakes更新了quote，当异步行为松散耦合时，它将更自然/更容易实现。DI仍然会添加为什么它更容易实现的原因。可能大多数发布子系统都允许异步订阅，但答案是这样写的，这是不合理的。也许需要注意关注点的分离。@flakes使用第三个组件broker来帮助实现异步行为，因为执行变得松散耦合。拥有多个主题如何？在观察者模式中，我只能有一个主题。然而，通过事件总线，我可以在许多不同主题的状态下更新事件。这难道不是使用事件总线优于观察者模式的优点/好处吗？@eansn你有一个观点，但是多个主题和一个观察者也可以称为观察者模式，请参见