オブザーバーデザインパターンと「リスナー」
GOFで説明されているObserverのデザインパターンは、さまざまなツールキットにあるリスナーと実際には同じものであるように思えます。概念に違いはありますか、それともリスナーとオブザーバーは本当に同じものですか。
（特定のコンピューター言語の実装を探しているわけではありません。デザインの観点から違いがあればそれを理解したいだけです。特定の言語に関する特定の質問で-私は言語の答えではなく、デザインの答えを探しています。）
「リスナー」という用語がオブザーバーパターンを指すかどうかは、コンテキストによって異なります。たとえば、Java Swingの「イベントリスナー」はObserverパターン実装の一部ですが、.Net「トレースリスナー」はそうではありません。
フレームワークの作成者が特定のパターン実装に参加するコンポーネントに異なる名前を割り当てることは珍しくありませんが、パターン自体について議論するときは、公式のパターン名が一般的に使用されます。
設計に関しては、特定のパターンの実装は、使用されている言語とプラットフォームの影響を受けることがよくあります。そのため、特定のフレームワーク内でのObserverパターンの特定の実装（ConcreteObserverの役割を表すために「リスナー」という用語を使用する場合があります）は、Design Patternsブックで説明されている実装とはわずかに異なる場合があります。
Gamma et。によるデザインパターンでのオブザーバーの記述には双方向の性質があります。 al。 （GoF）。
Observerの説明では、ConcreteObserversの1つがSubjectの変更を通知する場合があります。すべてのConcreteObserverのリストを保持するサブジェクトは、そのリストに通知します。原動機を含むすべてのConcreteObserversは、必要に応じて反応します。
リスナーの一般的な実装は、すべて外部からのイベントに反応するようです。
したがって、リスナーは、オブザーバーの一般化されていないケースであると言えます。
リスナーは、オブザーバーパターンの実装である可能性があります。リスナーは基本的に、特定のオブジェクトでイベントが発生するのを待っています。これはオブザーバーの役割です。
言語固有の回答を求めているわけではないことは承知していますが、このことについて抽象的に語るのは少し難しいです。したがって、.NETでこれを調査する場合、.NETリフレクターでリスナーを含むアセンブリを開く傾向があります。これにより、アセンブリを逆アセンブルし、そのロジックをデザインパターンと照合できます。