java - 观察者 : Implement with pattern (subject & observer) or inter-thread communication (wait & notify)

Question

我通常使用 Observer pattern，虽然我的同事在工作中已经实现了一个使用线程相互通信的观察者(使用 wait 和 notify/notifyAll) .

我应该使用模式来实现我的观察者，还是应该使用等待和通知来实现线程间通信？是否有充分的理由避免一种方法而总是使用另一种方法？

我总是选择第一个，使用模式，不符合惯例，因为它看起来更具表现力(涉及的标识符是表达和理解沟通内容以及沟通方式的好方法)。

编辑:

我在 Swing GUI 中使用模式，他在 Android 应用程序中使用线程间解决方案。

在他的解决方案中，一个线程生成数据然后调用notify，以唤醒另一个线程绘制生成的数据并在每次绘制后调用wait。

他对 wait/notify 解决方案的论点是，它创建的线程更少，甚至对 notify 的多个并发调用也只会导致 1 次绘制事件，而基于观察者的解决方案会在每次调用时调用重绘。他说这只是另一种有效的方法，但并未声称他这样做是出于性能原因。

我的论点是，我会在 OO 设计级别表达对象之间的通信，而不是使用使通信几乎不可见的特定于语言的功能。此外，低级线程通信很难掌握，其他读者可能难以理解，而应该在更高级别上实现，即。 e.使用 CyclicBarrier。对于一种或另一种解决方案，我没有任何合理的论据，但我想知道对于一种或另一种方法是否有任何合理的论据(即 “如果你使用这个，那么这个和那个可能会发生方法，而在另一种方法中这是不可能的。”)。

Answer 1

您正在比较苹果和橙子。等待/通知机制用于线程同步，虽然您的同事可能在 Observer/Observable 实现中使用过它，但它本身并不是模式实现。它只是意味着它是一个多线程实现。

此模式有很多实现，它们通常是根据您的工作环境量身定制的。大多数 UI 框架/工具包中都内置了事件机制。用于分布式环境的 JMS，...

我发现 JDK 提供的通用 Observer/Observable 类用处不大，根据经验，我也没有发现很多其他开发人员使用它们。大多数人会在适当的情况下使用提供的机制，或者在需要时推出他们自己的特定且最终更有用的实现。

由于最近我的大部分编码都是在 OSGi 环境中完成的，所以我更喜欢观察者/可观察对象的变体，称为 whiteboard pattern。 .这对您来说可能可行也可能不可行，具体取决于您的环境。