我通常使用Observer 模式，我的同事在工作中使用了线程互通（使用wait和notify / {{1 }}）。
我应该使用模式实现观察者还是使用wait和notify实现线程间通信？是否有充分理由避免使用其他方法并始终使用另一种方法？
我总是选择第一个，使用模式，超出惯例，因为它似乎更具表现力（涉及的标识符是表达和理解传达内容以及如何传达的好方法）。
编辑：
我在Swing GUI中使用该模式，他正在使用Android应用程序中的线程间解决方案。
在他的解决方案中，一个线程生成数据，然后调用notifyAll，唤醒另一个绘制生成数据的线程，并在每次绘制后调用notify。
他对wait / wait解决方案的论证是它创建了更少的线程，甚至几个并发调用notify只会导致1个绘制事件，而基于观察者的解决方案会每次通话都要重新打电话。他说这只是另一种有效的方法，但并没有声称他是出于性能原因而做的。
我的论点是，我会在OO设计层面上表达对象之间的通信，而不是使用特定于语言的功能，使通信几乎不可见。此外，低级线程通信很难掌握，可能很难被其他读者理解，而应该在更高层次上实现，i。即使用notify。我没有任何一个或另一个解决方案的声音参数，但我想知道是否有任何一个或另一个方法的声音参数（即“这可能发生，如果你使用这个方法，而另一方则不可能。“）。
答案 0 :(得分：2)
您正在比较苹果和橘子。等待/通知机制用于线程同步，虽然您的同事可能已在Observer / Observable实现中使用它，但它本身并不是模式实现。它只是意味着它是一个多线程实现。
此模式有许多实现，它们通常根据您工作的环境进行定制。大多数UI框架/工具包都内置了事件机制。适用于分布式环境的JMS，......
我发现JDK提供的泛型Observer / Observable类并没有太多用处，而且从经验中我还没有发现许多其他开发人员也使用它们。如果需要，大多数人将使用提供的机制，或者根据需要推出他们自己的特定和最终更有用的实现。
由于我最近在OSGi环境中完成了大部分编码，因此我倾向于使用名为whiteboard pattern的observer / observable变体。根据您的环境，这可能适用于您，也可能不适用。
答案 1 :(得分：2)
你应该避免，或者更确切地说，避免在99.99％的情况下进行线程间通信。如果确实需要多线程解决方案，则应使用更高级别的并发机制，例如ExecutorService或良好的并发库，例如jetlang：http://code.google.com/p/jetlang/。
答案 2 :(得分：1)
困难。我通常在没有显式编写多线程应用程序时使用Observer / Observable。但是，在这种情况下的惯例可能是您使用他的设计。也许看看你是否可以某种方式将它抽象出来，以便在必要时可以在稍后阶段用Observer模式替换它？
但是，我发现这两篇文章似乎表明Java中的Observer / Observable模式并不理想，应该避免使用。