オブザーバーの設計パターンと「リスナー」

GOFで説明されているオブザーバーの設計パターンは、さまざまなツールキットにあるリスナーと本当に同じものであるように思えます。概念に違いはありますか、それともリスナーとオブザーバーは本当に同じものですか？

（特定のコンピューター言語の実装を探しているのではなく、設計の観点から（もしあれば）違いを理解したいだけです。はい、SOFに関する同様の質問に対するいくつかの回答があることは知っていますが、それらは根付いています特定の言語に関する特定の質問-言語の回答ではなく、デザインの回答を探しています。）

「リスナー」という用語がオブザーバーパターンを指すかどうかは、コンテキストに依存します。たとえば、Java Swingの「イベントリスナー」はObserverパターン実装の一部ですが、.Net「トレースリスナー」はそうではありません。

フレームワークの作成者が特定のパターン実装に参加しているコンポーネントに異なる名前を割り当てることは珍しいことではありませんが、公式のパターン名は通常、パターン自体を説明するときに使用されます。

設計に関しては、特定のパターンの実装は、使用されている言語とプラットフォームの影響を受けることがよくあります。そのため、特定のフレームワーク内でのObserverパターンの特定の実装（コンクリートオブザーバーの役割を説明するために「リスナー」という用語が使用される場合があります）は、設計パターンブックで説明されているものと少し異なる場合があります。

ガンマらによるデザインパターンのオブザーバーの説明には、双方向の性質があります。al。（GoF）。

オブザーバーの説明では、ConcreteObserversの1人がサブジェクトの変更を通知する場合があります。すべての具象オブザーバーのリストを保持するサブジェクトは、そのリストに通知します。次に、原動機を含むすべての具象観測者が適切に反応します。

リスナーの一般的な実装は、すべて外部からのイベントに反応するようです。

したがって、リスナーは一般化されていないオブザーバーのケースであると私は言うでしょう。

リスナーは、オブザーバーパターンの実装である場合もあります。リスナーは基本的に、特定のオブジェクトでイベントが発生するのを待機しています。これは、オブザーバーが行うことです。

あなたは言語固有の答えを求めているのではないことを知っていますが、抽象的にこのことについて話すのはちょっと難しいです。したがって、これを.NETで調査する場合、リスナーを含むアセンブリを.NETリフレクターで開く傾向があります。これにより、アセンブリを分解し、そのロジックを設計パターンと照合できます。