イベントが関係するプログラミング環境のデメテルの法則を調整しようとしています-両方ともイベントを許可するため、このjavascriptとobj-c（CocoaのNSNotificationCenter）にタグを付けました。
このような環境では、イベントをスローしてバインド/サブスクライブするだけで、任意の2つのオブジェクトを任意に分離できます。obj-cでは、メソッドを呼び出す必要のあるオブジェクトへの参照を渡す代わりに、これを行う方がはるかに簡単です。これはおそらく常に使用するのは良くないと思います。パフォーマンスの観点から、メソッドディスパッチの最適化を見逃します（巨大なアプリでない限り、おそらく無視できます）。読みやすくするために、プログラマーは、あるオブジェクトが別のオブジェクトの依存関係であることを明示したい場合があります。これは、オブジェクトがイベントをスローするだけでは明らかではありません。
ソフトウェアアーキテクチャにおけるイベントの役割について考えてみたいと思います。イベントバインディングと直接メソッド呼び出しのバランスをどのように取っていますか？
用語に注意してください。GUIコンテキストでの「イベント」という言葉は、多くの場合、マウスクリック、タップ、キー押下などのユーザー生成イベントを意味し、これらの種類のイベントは通常、参照しているように見えるオブザーバーパターンを使用して処理されません。CocoaおよびCocoa-Touchでは、ユーザーイベントは責任の連鎖パターンを使用して処理されます。
どちらのパターンもオブジェクト間の緩い結合を促進しますが、オブザーバーの結合はおそらく緩いです。責任の連鎖に参加するオブジェクトは、通常、すべて共通の基本クラスから継承するか、または何らかの共通のインターフェイスに準拠し、連鎖内の各オブジェクトは、通常、連鎖内の隣接オブジェクトを認識します。オブザーバーを使用すると、メッセージを送信するオブジェクト（Cocoaの通知など）は、どのオブジェクトがメッセージを受信する可能性があるかを認識しません。また、メッセージを受信するオブジェクトは、通常、メッセージがどこから送信されたかを認識しません。特にCocoaとNSNotificationCenterには、共通のインターフェースすらありません。各「オブザーバー」オブジェクトは、通知を受信するためにサインアップするときに通知ハンドラーを登録します。
使いすぎると、オブザーバーパターンがかなり混乱する可能性があります。メッセージのもつれをデバッグすることは非常に難しい場合があります。さらに悪いことに、メッセージがオブザーバーに同期的に配信される場合（通常はそうです）、メッセージを送信するオブジェクトは、メッセージの送信にかかる費用を知る方法がなく、メッセージを受信するオブジェクトは、自身のパフォーマンスを認識できません。アプリケーションの残りの部分に影響を与える可能性があります。通常、特定のメッセージのオブザーバーの数に制限がないため、実際のパフォーマンスの問題が誤って発生しやすくなります。デメテルの法則の支持者は、彼らの舌をクリックして「私はあなたにそう言った」と言うかもしれませんが、それはあなたがオブザーバーを避けるべきだという意味ではありません。オブザーバーがメッセージに応じて多くの重労働を行うべきではないことを理解した上で適切に使用され、