使用するすべてのクラスが疎結合されている場合に直面する問題は何ですか
疎結合クラスは柔軟性を提供します。私が正しく理解していれば、イベントフロー、オブザーバーパターン、MVCなどのデザインパターンは疎結合に焦点を当てています。したがって、このコンテキストでは、すべてのクラスが疎結合されたプロジェクトを作成することを目指しています。
したがって、たとえば、Bを使用するクラスAがあります。
次に、a.b.doThis() ;の代わりに
私はこのようになります：
b.addEventListener( B.OnEventHappens, doThisInA ) ;
だから、私の質問はです。プロジェクト全体でこのような疎結合の関係が適切な場合はどうでしょうか。それは頑強なプロジェクトになるでしょうか？それとも、「エクストリーム」側で使用することはお勧めできませんか？
あなたが説明したもの以外にも多くの種類のカップリングがあります。別のコードが変更されたために1つのコードが変更されるのは、結合です。さまざまなコードを連携させる必要があるため、すべての結合を回避することはできません。
とにかく、カップリングだけが懸念事項ではないため、トレードオフがあります。たとえば、オブザーバーパターンを使用すると、誰が実際に監視を行っているかを判断する合理的な方法がないため、コードが読みにくくなり、静的に分析されなくなります。
すべての状況で明らかに常に最良の選択であるプラクティスがあった場合、基本的にそれが他の方法で行われることは決してありません。
結合の緩みと複雑さの間には、達成する必要のあるバランスがあります。アーキテクチャ全体の責任者として、そのバランスをとる必要があります。
オブジェクトに対してToString()メソッドを呼び出すと、すべてのクラスがToString()メソッドを持つ基本クラスから派生していることがわかっているため、安全に呼び出すことができます。より良い出力を実現するために、派生クラスでオーバーライドされます。イベントリスナーをToString()に追加しますか？いいえ、しません。何故なの？それは追加の利益なしに追加の複雑さを追加するからです。
アクションを受信するための対応するターゲットがある場合とない場合があるアクションにイベントリスナーを追加しますか？もちろん。どうして？これは、クラスモデルを一般化し、適切な場所でオプションのメッセージパッシングを許可するためです。
常に連携する2つのクラスがあるが、そのメソッドが他のクラスと通信しない場合（少なくともそれぞれのインターフェイスの領域内で）、それらをイベントと切り離すことはありません。どうして？デカップリングはそのコンテキストでは意味がないためです。正しく機能するために一方のクラスが他方のクラスの状態を知っている必要がある場合があるため（つまり、努力を調整する必要がある場合）、デカップリングは実際には事態をより困難にする可能性があります。デカップリングにより、クラスはお互いについてlessを認識しますが、それ以上ではありません。