觀察者：以模式（主題和觀察者）或線程間通信（等待和通知）實現

Question

我通常使用Observer 模式 ，盡管我的同事在工作中使用線程互通（使用wait和notify / notifyAll ）實現了一個Observer。

我是否應該使用模式或使用等待和通知的線程間通信來實現我的觀察者？ 是否有充分的理由避免一種方法而始終使用另一種方法？

我一直都使用第一個方法，使用了模式，這與慣例不符，因為它似乎更具表達力（涉及的標識符是表達和理解所傳達的內容以及如何傳達的一種好方法）。

編輯：

我在Swing GUI中使用模式，他在Android應用程序中使用線程間解決方案。

在他的解決方案中，一個線程生成數據，然后調用notify ，以喚醒另一個繪制生成的數據的線程，並在每次繪制之后調用wait 。

他對wait / notify解決方案的論點是，它創建的線程更少，甚至幾次並發的notify調用都將僅導致1個paint事件，而基於觀察者的解決方案將在每次調用時都調用一次repaint。 他說，這只是另一種有效的方法，但並沒有聲稱出於性能原因而這樣做。

我的觀點是，我將在OO設計級別上表達對象之間的通信，而不是使用使通信幾乎不可見的特定於語言的功能。 同樣，低級線程通信很難掌握，可能難以被其他讀者理解，而應該在更高級別上實現，即使用CyclicBarrier 。 我沒有一種或其他解決方案的合理論據，但我想知道一種或另一種方法是否有任何合理論據（即“如果使用這種方法，可能會發生這種情況，而在另一種不可能的情況下。” ）。

Answer 1

您正在比較蘋果和桔子。 等待/通知機制用於線程同步，雖然您的同事可能已在Observer / Observable實現中使用了它，但它本身並不是模式實現。 它只是意味着它是一個多線程實現。

此模式有許多實現，它們通常是針對您所工作的環境量身定制的。 大多數UI框架/工具包都內置有事件機制。 適用於分布式環境的JMS，...

我發現JDK提供的通用Observer / Observable類沒有太多用處，並且根據經驗，我也沒有發現許多其他開發人員也使用它們。 大多數將在適當的情況下使用提供的機制，或者在需要時推出自己的特定且最終更有用的實現。

由於我最近在OSGi環境中完成了大部分編碼工作，因此我傾向於選擇觀察者/可觀察者的變體，稱為白板模式 。 根據您的環境，這可能對您而言可行或不可行。

Answer 2

在99.99％的情況下，您應該避免甚至避免線程間通信。 如果確實需要多線程解決方案，則應使用更高級別的並發機制，例如ExecutorService或良好的並發庫，例如jetlang： http : //code.google.com/p/jetlang/ 。

Answer 3

難。 當不顯式編寫多線程應用程序時，通常會使用Observer / Observable。 但是，這種情況下的約定可能適合您使用他的設計。 也許看看您是否可以以某種方式抽象它，以便在必要時可以在以后的階段將其替換為Observer模式？

但是，我發現這兩篇文章似乎表明Java中的Observer / Observable模式不是理想的，應該避免。

觀察者和事件生成器慣用法 的內部視圖