design-patterns - EventListenerは監視可能ですか？

Question

私は現在、デザインパターンに関するクラスをフォローしていて、それEventListenerがObservable？

どちらにもサブスクライバーのリストがあり、何かが変更されたときにこれらのサブスクライバーに通知するため、実際には違いはわかりません。

Answer 1

AnObservableは、そのアクションを観察できる単なるオブジェクトです。したがって、アクションを聞いて、アクションが発生したことを通知できるものはすべてですObservable。

これは、イベントリスナーが1つであることを意味します。あなたはイベントを聞くことができ、イベントはそれらが起こったことをすぐにあなたに通知するからです。

個人的に誰かがObservable私がイベントだと思うと言うとき。これは、オブザーバブルが何であるかについての私のクッキーカッターの例です。同様の例は、異なる名前のイベントであるパブリッシュ/サブスクライブシステムです（微妙に異なるユースケースがあります）。

Answer 2

私の経験では、イベントリスナーパターンはオブザーバーデザインパターンとは異なります。それは単なる別の名前ではなく、その一部でもあります。

これについて具体的に話さなければなりません。たとえば、このページでは、イベントリスナーシステムのac＃実装を示しています。このシステムでは、リスナーはそのイベント処理関数をシングルトンクラスに登録しEvents、特定のタイプのイベントを処理できると主張します。Events各タイプのイベントをそのハンドラー関数にマップするためのディクショナリを維持します。一方、イベントをトリガーしたいクラスは、シングルトンの関数を介してトリガーする必要があります Events.instance.Raise()。

ここで3つの違いを見ることができます：

まず、2つのパターンの目的は異なります。リスナーデザインパターンは、イベント検出/発生コードをイベント処理コードから切り離し、新しいイベント処理コードを変更または追加するときに、他のイベント処理コードに影響を与えないようにすることです。オブザーバーデザインパターンは、別のオブジェクトの変更に追従するようにいくつかのオブジェクトを作成することです。

データ構造も異なります。リスナーデザインパターンでは、各タイプのイベントをその処理メソッドにマップするグローバルディクショナリは1つだけです。このマッピングは1対1です。オブザーバーパターンにいる間、すべての観察対象はオブザーバーのリストを維持します。このマッピングは1対多です。1つは多くのオブザーバーの影響を受けます。このような1対多のサブジェクトとオブザーバーの関係には複数のインスタンスが存在する可能性があります。

動作が異なります。Events.instanceリスナーデザインパターンでは、イベントが発生すると、イベントハンドラーに関する情報がないため、イベントレイザーはグローバルメディエーター（シングルトン）に通知します。オブザーバーパターンでは、変更が発生すると、観察対象はすべてのオブザーバーに直接通知します。

Answer 3

JDKのソースコードを調べて、自分自身もさらに調査を行いました。それらの唯一の違いはObservable、追加時に同期された使用ObserversとEventListenerそうでない使用（少なくともAbstractButton'sは同期されない）であると思います。

Answer 4

ええ、特定のイベントのリスナーを登録するイベントキューは、オブザーバーパターンの例のようです。