イベントが関わったときのDemeterの法則/単一責任

Question

イベントが関与するプログラミング環境でDemeterの法則を調整しようとしています - このjavascriptとobj-c（CocoaのNSNotificationCenter）の両方にイベントが許可されているため、

このような環境では、イベントをスローしてバインド/サブスクライブするだけで、任意の2つのオブジェクトを任意に切り離すことができます。 obj-cでは、メソッドを呼び出す必要があるオブジェクトへの参照を渡す代わりに、これを行うほうがずっと簡単です。私はこれはおそらく常に使用することは良いとは思わない：パフォーマンスの観点では、メソッドディスパッチの最適化を逃している（それは巨大なアプリケーションでなければ、おそらく無視できる）。読みやすさのために、あるオブジェクトが別のオブジェクトの依存関係であることを明示したい場合があります。

私は、ソフトウェアアーキテクチャにおけるイベントの役割に関するいくつかの考えをお伝えしたいと思います。イベントバインディングと直接メソッド呼び出しのバランスをどのようにしたいと思いますか？

Answer 1

用語に注意してください。 GUIコンテキストの「イベント」という単語は、マウスクリック、タップ、キー押下などのユーザー生成イベントを意味することがよくありますが、この種のイベントは通常、参照していると思われるobserver patternを使用して処理されません。 CocoaとCocoa-Touchでは、ユーザーイベントはchain of responsibility patternを使用して処理されます。

両方のパターンはオブジェクト間の疎結合を促進しますが、オブザーバでの結合はおそらく緩やかです。責任の連鎖に参加するオブジェクトは、一般的にすべて共通の基底クラスから継承するか、または何らかの共通のインタフェースに準拠しており、チェーン内の各オブジェクトは一般的にチェーン内の隣接ノードを認識します。オブザーバでは、メッセージを送信するオブジェクト（Cocoaでの通知など）は、どのオブジェクトがメッセージを受け取るかを知らず、メッセージを受け取ったオブジェクトは通常どこから来たのか分かりません。特にCocoaとNSNotificationCenterでは、共通のインターフェイスもありません。各「オブザーバ」オブジェクトは、通知を受け取るためにサインアップするときに通知ハンドラを登録します。

あなたが過度に使用した場合、オブザーバーパターンでかなり混乱を生むことができます。メッセージの混乱をデバッグすることは非常に困難です。さらに悪いことに、メッセージがオブザーバーに同期して配信された場合（通常はメッセージが送信されている場合）、メッセージを送信するオブジェクトはメッセージを送信するのにどれくらいの費用がかかるかを知る方法がなく、メッセージを受信するオブジェクトは、残りのアプリケーションに影響を与える可能性があります。特定のメッセージに対するオブザーバの数が通常無制限であるという事実は、実際のパフォーマンスの問題を誤って作成しやすくします。 Demeter擁護者の法律は、彼らの言葉をクリックして「私はあなたに言った」と言っているかもしれませんが、それはあなたがオブザーバーを避けるべきではありません。適切に使用され、オブザーバーはメッセージに応じて大量の持ち上げを行うべきではないという理解のもと、必要な場所に情報を伝えるパワフルな方法であり、多くのものを不要にしてコードを単純化することができますオブジェクト間の関係。