Question

我是观察者模式的忠实粉丝。在我们的代码中，我们在许多地方使用它来相互分离服务。但是，我发现它在许多地方实施得很差，因为有很多地方需要担心：

异常处理 - 不希望侦听器抛出运行时异常。
长时间运行的侦听器阻止主线程
在我们迭代它的同时修改侦听器列表。

更重要的是，我们最终会在整个地方重复此代码。本着DRY的精神，我想将所有通知问题都纳入单一服务中。一些伪代码：

Interface NotificationService
   // register the listener to receive notifications from this producer
   registerAsListener (NotificationProducer, NotificationListener)

   // Sends a notification to listeners of this producer
   sendNotification (NotificationProducer, Notification)

   // Sends a notification in a background thread
   sendAsynchNotification (NotificationProducer, Notification)

   // Listener no longer receives messages from this producer
   removeListener(NotificationProducer, NotificationListener)

我的问题是：我是否通过这样做失去了观察者模式的原始点？我是否通过在模式的两个方面引入另一个依赖项而犯了错误？ Listener和Producer现在都将对NotificationService有额外的依赖。

您有什么看法？

Answer 1

你对自己的疑虑和问题是正确的。多次实现观察者模式似乎是简单的重复。你也是对的，上述解决方案确实失去了模式的目标。

您刚刚实施的是（全局？）事件总线。它是制作人和听众的矩阵。这对许多应用程序都很有用（参见GWT的事件bus）。

但是，如果您只想在保持模式的同时最小化代码重复。您可以删除侦听器和服务之间的耦合，使用上述接口的缩小版本作为被观察类的成员。所以注册和通知的逻辑只写一次。被观察的类只是将注册和通知逻辑委托给服务。

class ObservedClass implements Observable {
    NotificationService notificationService = new NotificationServiceImpl (this);
    ....
 }

interface NotificationService {
   // register the listener to receive notifications from this producer
   registerAsListener ( NotificationListener)

   // Sends a notification to listeners of this producer
   sendNotification (Notification)

   // Sends a notification in a background thread
   sendAsynchNotification (Notification)

  // Listener no longer receives messages from this producer
  removeListener(NotificationListener)

将观察者模式拉出到服务中

1 个答案: