回答:
イベント/リスナーのアプローチは密結合を回避しようとするため、すべてのコードの臭いがそのことを示すので、そのアプローチがポイントされます。
それに基づいて、私は次の症状を提案します：
すべてのオブジェクトが他のすべてのオブジェクトを認識する必要があり、それなしでは機能できないため、大きなコンストラクター。obj.set_dependecy(x)コンストラクタの呼び出しの直後に、多くの人が偽装している可能性があります。
双方向の依存関係。なぜなら、イベントがなければ、命令型言語では、情報のフローは基本的に「プッシュ」される（誰かのメソッドを呼び出す）ためです。
「知識の階層」を決定するのは難しい。これは双方向の依存関係であり、もう1つの焦点です。BをリッスンするAがある場合、AはBを認識しますが、BはAを認識しないため、「階層」があります。など。たとえば、次のようにMVCを実装する場合：http : //en.wikipedia.org/wiki/Model_View_Controller、モデルは自身のみを認識し、ビューはモデルを認識し、コントローラーはビューとモデルを認識します。
私はあなたの質問を変えて言うでしょう：イベントベースはオブジェクト指向アプリケーションの正しい解決策ではないとき？ほとんどのOOアプリケーションは、イベントプロデューサーおよびコンシューマーとして設計されている場合にメリットがあると思います。
結局のところ、「メソッド呼び出し」は実際にはオブジェクトに到着するメッセージであり、オブジェクトはメッセージで何かを行うかどうかを決定し、操作を実行する責任があります。これは、Javaなどの強く型付けされた言語ではあまり明確ではありませんが、Rubyなどの動的言語ではより明確になります。
アプリケーションをイベントベースとして設計するもう1つの興味深い点は、通常、内部コンポーネントを適切に分離して一貫性を持たせる必要があることです。そうしないと、コードが非常に速く混乱します。例として、私はAlistair Cockburnによって使用される六角形アーキテクチャの概念が本当に好きです。通常、このパターンは、より良いカプセル化を作成し、（私の見方では）より凝集性のあるコンポーネントを強制します。
これはおそらくドメインドリブンデザインのドメインイベントの概念にも関連していると思いますが（おそらく間違いです）、ドメインクラスは他のオブジェクトによってキャプチャされたイベントを発行し、これらのオブジェクトはさらに他のイベントを発行します（これは：D）です。このパターンで私が気に入っているのは、インターフェースは実装ではなくロールをモデル化する必要があるということです。
あまり意味がわからない場合は申し訳ありませんが、過去数か月間これらのパターンを実験して素晴らしい結果を出してきましたが、コンセプトとそれらがどの程度到達するかを理解しようとしています。
イベントリスナー（別名：オブザーバーパターン）が存在しなかった場合の対処方法を考えてください。
他のオブジェクトのリストへの参照があり、プロセスの特定の時点でそれらのメソッドを呼び出すオブジェクトがある場合、そこにイベントがあったはずです。
オブジェクトに何かが行われたことを示すフラグがあり、他のオブジェクトからそのフラグを監視している場合は、イベント駆動型モデルを使用する必要があります。
ただし、これをコールバックと混同しないでください。別のオブジェクトのメソッドを呼び出して、元のオブジェクトのメソッドに渡し、特定の時間にコールバックする場合は、イベントリスナーを使用するのではなく、そのままにしておきます。