オブザーバーパターンとイベント駆動型アプローチの違い
オブザーバーパターンは、通常のイベント駆動型のアプローチとほぼ同じであることが常にわかりました。実際、私はそれらが実際には同じものを指す異なる名前であるとほとんど信じていました。どちらも同様の概念を使用してリスナーとして何かを持ちますが、実装においてもほとんど同じです。アクションを実行するためのコールバックメソッド/関数を持ちます。これは少なくともJavaの場合です。
他の言語では、Actionscript/Flexと言うと、イベントはよりユーザーフレンドリーであり、オブザーバーパターンが定義する以上のことをするように見えるかもしれません。それでも、概念は同じように聞こえます。
しかし、これは本当に本当ですか？オブザーバーパターンは、通常のイベント駆動型プログラミングスタイルと同じものですか？
オブザーバーパターンは非常に特別なインスタンスです。イベントドリブンは何を意味してもかまいません。ほとんどのオブザーバーパターンの実装では、オブザーバーはオブザーバを監視するオブジェクトです。オブザーバが変更されると、オブザーバーのメソッドが呼び出されます。厳密に言えば、これは「イベント」ではありません。つまり、オブザーバに対するさまざまなアクションは、通常、オブザーバーで異なるメソッドの呼び出しにつながります。変更されたセマンティクスの「何」がメソッドにあります。イベントドリブンシステムでは、基本的に1つの消費オブジェクト/メソッドと、何が変更されたか、何が起こったのかというメッセージがイベントにあります。それは何でもよく、何かを観察するという考えに限定されません！つまり、イベント駆動型システムでは、新しいイベントタイプを追加することで新しいセマンティクスを取得できます。 Observerパターンでは、通常、Observerクラスにメソッドを追加してセマンティクスを追加します。ただし、ChangeEventsの特別なリスナとしてObserverを実装することを妨げるものは誰もいません。
パブリッシャーまたはサブジェクトで状態が変化した場合、
イベント駆動型アーキテクチャ（メッセージ駆動型アーキテクチャ）、配信サブスクライバへのメッセージを非同期的に処理します。
オブザーバーパターン（ソフトウェアデザインパターン）、コマンドサブスクライバーが同期して何かを行う役割を担います。
イベント駆動型プログラミングは、パラダイムを定義する用語です。一方、Observable patternは、アプリケーションをイベント駆動型にするための設計ソリューションです。
乾杯！
違いNo.1は、イベントシステムが常にオブザーバからオブザーバブルを分離するイベントディスパッチスレッドを持っているため、イベントがオブザーバーにすぐに届かない場合があります。実際のオブザーバブルはオブザーバーメソッドを直接呼び出しますが、イベント駆動型オブザーバブルはイベントをイベントキューにドロップします。次に、EDTはこれらのイベントを登録済みリスナーに配信します。
この質問の複数の回答からの合成、これは hackernoonの記事 であり、私自身の経験では、ObserverパターンとEvent-Driven（Pub-Sub、たとえば）アーキテクチャの主な違いは、 ：
Observerパターンでは、ObservedはObserversへの参照を維持します。
一方、Pub-Subでは、ブロードキャスターはリスナーが誰なのかわかりません。 （または、誰かがリッスンするためにそこにいたとしても。）リスナーはブロードキャスターからのデータを期待するかもしれませんが、イベントがどこから来たのか正確にはわかりません。多分それは複数のクラスやリモートシステムから来ています。そうでないかもしれない。ブロードキャスターまたはリスナーのどちらでもかまいません。
さて、それはこれらのことは非常に異なっていると言うことではありません。また、どちらかまたは両方のように動作する実装があります。
たとえば、 wisper rubygem を使用すると、必要に応じてObserverパターンまたはPub-Subパターンのように動作できます。必要に応じて両方を併用することもできます。
この同じ質問を少し検索しました。このスレッドでは、Angel O'Sphereの「セマンティクスとは何か」という点と、「Dispatcher」のSpaceratが役立つと思う点があります。
その2点は、Even-DriverとObserverパターンを区別する私の理解です。少なくとも標準的な説明から、「オブザーバーパターン」は通常、「サブジェクト」が変更され、サブスクライバーまたはリスナーが提供するインターフェイスを呼び出すことで「ディスパッチング」が実装されるとすぐにブロードキャストを表します。イベントドリブンの場合、「Subject」と「Observer」の間に常に別のレイヤーがあります。「Dispatcher」または「Event Queue」を使用します。これにより、CPU使用量を減らす「遅延」処理が提供されます。インターフェイスは異なるイベントタイプに依存します。
それは非常に簡単だったのです。
ただオブザーバーとオブザーバブルとして考えてください。オブザーバブルはsetChangedをマークし、オブザーバーはオブザーバブルに変更内容を要求する代わりに、オブザーバーは変更に関するすべての関連情報を含むオブジェクト（Event Carried State）をオブザーバーにブロードキャストします。したがって、実際にはObserverとObservableの間にもう1つのインスタンスがあります。
http://www.grahambrooks.com/event-driven-architecture/patterns/stateful-event-pattern/
両者の基本的な違いは、カップリングと同期動作です。オブザーバーパターンに固執する場合、シグナルのソースは1つだけであり、それは同期的であると言いますが、一方、イベントでは、両方のパーティを独立して動作するように切り離し、同時に複数のソースを持つ可能性を楽しませますコード変更なしの将来のイベント。イベントは、非同期を設計として採用するのに役立ちます。すべてのリアクティブプログラミングライブラリは、イベント駆動型設計に対して非常に優れたサポートを提供します。
Wikipedia から：
オブザーバーパターンは、サブジェクトと呼ばれるオブジェクトがオブザーバーと呼ばれるその依存関係のリストを保持し、通常はメソッドの1つを呼び出すことにより、状態の変化を自動的に通知するソフトウェア設計パターンです。
これは主に、「イベント駆動型」ソフトウェアで分散イベント処理システムを実装するために使用されます。 JavaやC＃などの最新の言語には、簡単なプログラミングと短いコードのために、オブザーバーパターンコンポーネントを実装する「イベント」コンストラクトが組み込まれています。
オブザーバーpatternはもう少し抽象的で理論的です。イベントは1つ（通常は組み込み）実装ですが、Angelの回答に記載されているように、イベントは他のいくつかの状況で使用できる傾向がありますオブザーバーパターンで厳密に定義されているもの。
はい、それらは主に同じです。
イベントは、一部の言語の「組み込み」オブザーバーパターンテンプレートのようなものです。
したがって、あなたが探しているものをすでに提供しているので、イベントをサポートする言語でオブザーバーパターンを実際に実装することはないでしょう。
一方、オブザーバーパターンを使用すると、イベント駆動型の言語でイベント駆動型を記述できます。