观察者模式的替代方案答案

【问题标题】：Alternative to Observer Pattern观察者模式的替代方案
【发布时间】：2011-07-07 09:19:22
【问题描述】：

有谁知道 Observer 又名 Listener 模式的替代方案？我对在异步中运行良好的东西感兴趣环境。

我面临的问题是我有一个使用它的应用程序模式很多，这本身并不是一件坏事，但随着听众数量的增加，它会成为一个瓶颈。结合线程原语（互斥体、关键部分——当然是在我的特定环境中）对性能的影响非常糟糕。

【问题讨论】：

监听器是并行工作还是串行工作？
我认为任何替代方案都将在很大程度上取决于具体情况。
@ericgorr 无法提供更多细节。我对模式的一般替代方案非常感兴趣；希望我自己找出适合我特定情况的那个。不要误会，但我认为这些细节不会有任何帮助。

标签： multithreading performance oop design-patterns observer-pattern

【解决方案1】：

如果减少代码中的侦听器是您的主要目标，请查看它Jeffrey Richter and his AsyncEnumerator。这种技术使异步编程看起来更像同步。

使用这种技术，您的单个方法可以发出异步调用并恢复该方法充当事件处理程序，因此整个调用和事件侦听器代码可以合并为一个功能。

【讨论】：

这是 C# 特有的，它依赖于一些 C# 编译器的“魔法”。我一直在寻找不依赖于某种语言功能的东西。

【解决方案2】：

Message Queue怎么样？

【讨论】：

这可能是一个很好的解决方案，虽然，所以我读到，它有它自己的头痛。我会试一试。谢谢
我看到消息队列通常最适合作为 Actor 模型的消息传递机制。

【解决方案3】：

如果观察者太多，所以被观察的线程没有任何进展，那么反转关系可能是明智的。与其让观察到的线程调用每个观察者，不如让观察者等待与观察到的线程相关的条件变量或事件之类的东西。然后观察者代码可以阻塞，等待条件变量发出信号。然后，被观察线程可以只向条件变量发出信号，而不是调用观察者；观察者可以在自己的时间内注意到信号并处理后果。

【讨论】：

这听起来不错，但它更像是一个改进的观察者。无论如何，我必须与每个观察者共享条件对象和关联的互斥锁，不是吗？或者想办法解决这个问题。除了等待条件发出信号之外，观察者线程可能还需要做其他事情。最重要的是，我可能有不在自己的线程中运行的观察者（观察者组）。无论如何，这是一个可以考虑的替代方案。谢谢
是的，您需要每个观察者都知道条件变量和互斥锁。或者，您可以为每个观察者设置一个，并让被观察的线程依次通知每个观察者。或者，您可以为每个观察者创建一个消息队列，因此被观察线程只是发布消息而不是发出信号。
如果您的某些观察者没有线程化，那么您可以启动一个新线程来处理它们。如果它们不是线程安全的，那么您在多线程应用程序中就会遇到更大的问题。

【解决方案4】：

我有两种选择：使用 actor 模型（如 akka 框架）或使用 executor 来限制并行化。 Executor 基本上只是一个线程池，它会限制线程的数量并重用已完成的线程。

【讨论】：

Executor - 是 Java 的吗？我没有使用 Java，我对与语言无关的解决方案很感兴趣。至于 Actor 模型，它看起来很有趣，但它需要对我的应用程序的范式进行彻底的改变——完全放弃我认为不适合我的具体情况的共享内存模型。无论如何，我会记录更多关于它的内容。

【解决方案5】：

很难说没有更具体的描述，但Mediator pattern 是相关的，可以在通信对象的数量开始激增时使用。您可以实施一些政策，以更结构化的方式协调这些活动。

【讨论】：