ときどき、イベントをトリガーする前にいくつかの複雑な条件を満たしている必要があるシナリオに遭遇しました。さらに、ほとんどのリスナーは、追加のチェックを実行してアクションのコースを決定します。これにより、小さなイベントの観点から考えて、それらを相互にトリガーさせることがより良い解決策になるかどうかを考えさせられました。
イベントを連鎖させることで、後から追加のリスナーをかなり少ない労力で織り込むことができます（YAGNI違反の可能性があります）。私のコードは簡単に理解できる単純な要素で構成されますが、他の人が理解するのは難しくありません。
ただし、このソリューションの潜在的な欠点は、チェーン内で何か問題が発生した場合（たとえば、ヒューマンエラーによる誤ったイベントトリガー）、バグをキャッチすることが非常に困難になるという事実です。
イベントは、良いアイデアの連鎖をさTMを？そうでない場合、イベント関連のコードが乱雑になるのを防ぐための代替方法は何ですか？
回答:
イベントチェーンは良いアイデアですか？
使用するまで、本当に良いアイデアのように思われるものの1つです。
順序に対する暗黙の依存性を伴わずにカスケードイベントを設定することは非常に困難です。無限ループと時折のメモリリークによる問題を引き起こすことなく、それらを設定することは困難です。これらは、接続する場所とカスケードする場所の両方を知る必要があるイベントによって引き起こされる結合により、クラス設計をより困難にします。
そして、彼らはデバッグとコードについての推論が非常に難しいです。
現在では、コードの構造がこれらの問題の一部を制限する比較的限られたシナリオで使用できる場合があります。UIでは、階層イベントが所有権とループの懸念を制限するのに役立つため、カスケードイベントを使用して階層をトリガーできます。
それでも、最近では、実行時に任意の動作をラッチさせるよりも、そのような拡張可能な動作のコンストラクタでデリゲートを受け入れることがはるかに多く見られます。
イベントチェーンは次の場合に良いアイデアです。
システムの構築を開始する前に、ソリューションを熟考し、いくつかのことを一般化することが非常に重要です。たとえば、OO言語では、すべてのイベントの基礎として基本的なインターフェイスまたは抽象クラスが必要です。そのクラスには、ロギング/デバッグなどを組み込む必要があります。また、障害を適切に処理するための一般化されたイベント管理クラスが必要な場合があります。
かつてイベントチェーン関連のエラーを追跡するために数日を費やした誰かの観点から言えば、これは非常に悪いアイデア（sm）です。既に述べたように、デバッグを悪夢にする制御フローを隠しています。誰かがコントロールをリセットするエラー処理コードを追加したとき、私は状況に陥りました。これにより、onPropertyChange、エラーハンドラーを持つコントロールを更新するハンドラー発生し、他のコントロールを再度リセットするなどにつながりました。基本的に、UIはCPUが100％に固定された状態でロックアップします。
同じルートイベントに対してイベントハンドラーが複数回トリガーされるのを防ぐ方法があれば、これを回避できるかもしれませんが、複数のイベントハンドラーの呼び出しが必要な状況を想像できます。
イベントチェーンを適切に実装することは、他の人が言及したすべての理由により困難です。
ただし、ほとんどのルールエンジンの基本的な前提でもあります。JBoss Drools、IBM jRules、PegaSystems、Corticon、およびFICO Blaze Advisorはすべて、システムで発生するイベントに基づいて起動するルールをユーザーが宣言できる主要なビジネスルール管理システム（BRMS）です。前方連鎖と後方連鎖の両方が可能であり、実行可能です。
Prolog言語とその派生語は、同じ概念に基づいています。
関係するアルゴリズムは単純ではなく、デバッグは苦痛になる可能性がありますが、モデルには多くの価値があります。
{A + B} > C > {D & E}。テストとデバッグは依然として苦痛です。