現在、オブザーバーパターンは業界で放棄されていますか（2019）？
レガシーアプリのリファクタリングタスクの作業中に、一連の原因->効果タイプのイベントが発生し、現在すべてがインラインで処理されているシナリオに遭遇しました。
あなたにアイデアを与えるために、ユーザーはファイルをアップロードし、それからいくつかのフォーマットに変換され、各フォーマット変換タスクの完了/失敗時に、事前定義された宛先に電子メールが送信され、電子メール配信が成功すると、一部のファイルに記録されました。
一見、オブザーバーパターンまたはpub-subの典型的な使用例のように見えますが、私は この投稿 および リンクされた論文 に遭遇しました。私は準備ができていないかもしれない混乱に終わるでしょう。
ソフトウェア業界の最新の変化については、かなり前から岩の下に住んでいます。オブザーバーが（もう）上記のタイプに属する問題を切り離すのに適切または適切な方法ではない場合、業界（業界では、ソフトウェアエンジニアの主流であると私は思います）に、知らない代替案をすでに提案しています。の？
オブザーバーパターンは、小規模なプログラムには適しています。あなたが述べたように、それはそのイベントに作用するクラスからイベントを適切に切り離します。
ただし、それを配線すると少し複雑になる可能性があり、イベント自体は分離されていますが、イベントを配線するには、少なくともある時点で、オブザーバーが主題について知っている必要があります。
したがって、一般的にこの種の問題に対する最も簡単なアプローチは、イベントバスまたはメッセージキューを使用することです。 AがBをリッスンし、BがCをリッスンし、CがDタイプの取引をリッスンするのではなく、イベントの登録とイベントのリッスンの両方が可能な中央イベント処理システムがあります。したがって、AはBが発行するイベントを登録し、BはCが発行するイベントを登録します。他のクラスが存在することをクラスが認識する必要はなく、イベントリスナーの登録中でも完全に分離できます。
また、イベント処理を一元化することにより、スレッドの処理に専念できるため、潜在的にイベントを生成して同時に処理できるという追加の利点もあります。主な仕事はこれであるため、ほとんどの場合これをメッセージキューと呼びます。
これをさらに一歩進めて、イベントがキューに到着したときにイベントをシリアル化することができます。そのため、イベントが実行される前にプログラムが失敗しても、おそらく進行状況が失われることはなく、イベントはまったく同じように発生します。
強調しておきますが、オブザーバーパターンは引き続き機能しますが、完全な分離ではありません。小規模なプロジェクトでは問題ありませんが、大規模なプログラムではイベントバスまたはメッセージキューを検討する必要があります。
全く逆です。
オブザーバーパターンは一部の言語やフレームワークで非常に有用であり、ファーストクラスのプリミティブとして採用されています。 C＃のイベントは、主要な例です。
オブザーバーパターンは、サービスが他のサービスによって生成されたイベントにサブスクライブできるアーキテクチャレベルでも見られます。
しかし、実際の問題は、オブザーバーとpub-subのパターンが実際に問題の良い解決策であるかどうかです。偶数を生成するものとそれを消費するものとの間に明確な分離がある場合、それらは本当に良いです。これは実際には非常にまれです。あなたが説明する例は、オブザーバーを使うのに本当に良い場所ではないと思います。ワークフロー全体が密接に結合されているように見えるので。
そして、建築レベルでは、すべてのイベントをブロードキャストして、登録したサブスクライバーだけに送信するのではなく、消費者に興味のあるものを選んでもらう方が良いようです。