14

A が B からの変更を待機し、B が C からの変更を待機し、C が A からの変更を待機してサイクルを形成するイベント ドリブン アーキテクチャがあります。

ここで、B が変更されると、A は C に対してイベントを発生させ、C は B に対して発生し、A は A に対して発生し、C は無限に発生します。

今すぐプログラムを変更して、このサイクルを含まないようにすることはできますが、後でそれができなくなり、追い詰められるのではないかと心配しています。イベントベースのシステムを設計するときに、そのようなことが起こらないようにするにはどうすればよいでしょうか?

4

5 に答える 5

5

ここの誰もが循環依存が悪いと言っているようです。これはある意味で正しいので、ほとんどすべてのコストで静的な循環依存を避けようとしています。このブログでスケッチされているように、制御の反転を使用してこれを行うことができます：http: //blog.schauderhaft.de/2011/07/17/breaking-dependency-cylces/

しかし、あなたが説明することは、静的な循環依存ではなく、実行時に必要です。完全にはわかりませんが、実行時に循環依存を回避することは多かれ少なかれ不可能だと思います。しかしもちろん、これによって無限ループが発生することはありません。それらを修正するには、2つ半のオプションが表示されます

最初にハック

別のイベントによってトリガーされた各イベントに、元のイベント（またはIDなどの重要な情報）への参照があることを確認してください。イベントを処理するときは常に、それが自分自身から発生したものではないことを確認してください。

プロ：実装が簡単。再帰を完全に防ぎます

ハックの残りの半分

同期を実行している場合は、firingEvent前にフラグを設定し、後でリセットすることができます。が設定されている間に発生するイベントを無視しますfiringEvent。

プロ：実装がさらに簡単です。シングルスレッドで実行しているときに再帰を完全に防止します

セマンティックリッチソリューション

Aが外部トリガーで発生するイベントと、Cが発生するためにAが発生するイベントは、実際には2つの異なるイベントであるか、3つのイベントすべてが、まだ特定されていないソースDから発生する可能性があるイベントであると確信しています。そんな感じ。A、B、Cが何であるか、そしてそれらがどのようなイベントを発生させているかを情報なしで知る方法はありません。適切なイベントを見つけると、サイクルは消えます。

長所：デザインはよりクリーンになり、より多くの情報が含まれます。

于 2012-04-18T14:22:06.203 に答える
2

依存関係を計画します。サイクルがあってはなりません。循環的な依存関係は、コードを再編成する良い口実です。

それらを回避しようとする別の理由が必要な場合は、デッドロックを引き起こす可能性もあります。

于 2010-09-10T20:34:01.360 に答える
2

イベントベースのシステムを設計するときに、そのようなことが起こらないようにするにはどうすればよいでしょうか?

  1. オブジェクトの状態が実際に変化した場合にのみイベントを発生させます。

  2. イベントの発生中にオブジェクトの状態が変化することを禁止します。

于 2015-07-24T17:04:23.380 に答える
0

これは良い質問だと思います。残念ながら、私自身は完全な答えを持っていませんが、この投稿にはいくつかの良い点があります。

オブザーバーパターンで無限ループを回避するには?

他の人が示唆しているように、答えは循環的な依存関係を避けることではないと思います。(まあ、それは「循環依存関係」の定義に依存します。) Java のような言語は、コンパイル時に型の循環依存関係を最小限に抑えるためにインターフェイスを使用します。これは多くの場合、良い考えです。たとえば、MVCパターンのビュー クラスはアプリケーションに「依存」せずValueChangedListener、ClickListener、 などの名前のインターフェイスしか認識しません。しかし、これは実行時にオブジェクト間の循環接続を排除しません。イベントループ。

他のリンクされた投稿で述べたように、コントローラーまたはモデルがビューの値を現在の値と等しい値に「設定」すると、ビューは「変更」イベントを発生させないため、UI ツールキットで一部のループが停止します。ただし、より複雑なデータのカスタム ビューを作成する場合など、現在のデータと新しいデータの等価性を計算することができない場合もあります。

于 2012-04-18T13:18:15.447 に答える
-3

循環依存は本当に悪いです。あなたの投稿をA、B、Cの観点から書き留める必要がありました. 私はあなたがそれを取り除くべきだと思います。追い詰められている場合は、循環依存関係で遭遇する可能性のある問題よりもはるかに優れている可能性があります。

これも確実に回避できます。A、B、および C は、非常に緊密に結合されています。彼らの責任を再考する必要があると思います。おそらく、設計上のストレスの多くを取り除く共通の D 要素があるでしょう。

他に頭に浮かぶのは、建築的なレイヤリングです。A を B の上に重ねることができ、B と話す人が A を通過して層を下っていくためにコミュニケーションを必要とする場合は、より簡単な時間を与えることができます。繰り返しますが、私はあなたの問題についてあまり知らないので、これらは大まかな提案にすぎません。

最後の 1 つのオプションであり、私が最も気に入らないオプションは、3 つのコンポーネントのそれぞれの間でメッセージを渡すことです。それぞれがアクセスされるたびに、各コンポーネントがメッセージを見たことをメッセージに追加する必要があります。次に、メッセージを取得する次のコンポーネントには、メッセージを見た人に関する情報が含まれています。サインアップシートのようなもの。しかし、繰り返しますが、最も好きではありません。最初に別のことを試してください。

幸運を！

于 2010-09-10T21:14:02.897 に答える