遠心性/求心性カップリングが良いか悪いか

今週はソフトウェアパターン試験があり、研究対象のトピックの1つは、遠心性カップリングと遠心性カップリングです。

パッケージが他の多くのタイプに依存する場合、そのパッケージのCe（遠心性結合）が高いことを理解しています。

例えば：

class Car{
    Engine engine;
    Wheel wheel;
    Body body;
}

このクラスは、エンジン、ホイール、およびボディのタイプに依存するため、遠心性の高いカップリングになります。

一方、他のいくつかのパッケージ（車、飛行機、自転車）に依存している場合、タイプ「ホイール」のCa（求心性結合）は高くなります。

私たちの試験で考えられる質問の1つは、Efferent / Afferentカップリングがいつ良いか悪いかです。論理的には、プログラムが高いEfferent / Afferentカップリングのパッケージ/クラスを必要とするため、これは私には奇妙に思えます。

誰かが、高遠心性または求心性結合がいつ/どこで良い/悪いかの例を持っていますか??

ありがとう！

求心性カップリングは、変更の必要性または可能性のためにどれだけの痛みが生じるか/保存するかという観点から最も簡単に評価できます。たとえば、ホイールクラスを取得し、他の多くのモジュールがそれを使用してさまざまな種類の車両を構築するとします。車輪のクラスが非常に安定している場合、車両には車輪が必要であり、信頼性の高い車輪を使用しているため、この求心性カップリングは有益です。一方、メンテナンスの観点からwheelクラスが揮発性である場合、この求心性カップリングは、多くのコードに繰り返し変更を導入する際の問題点になります。

遠心性カップリングの概念は似ていますが、わずかに異なる価値提案を見ることになります。多くの個々のパーツに直接依存する車のクラスがある場合（「エンジン」と「シャーシ」のみとは異なり、他のサブパーツで構成されている場合）、クラスはおそらく多くのことを行うため、メンテナンスのボトルネック。そのクラスの変更は、その複雑さのために困難でリスクが高い可能性があります。一方、遠心性のカップリングが高いが、実際には結束力があり明確である場合、心配するオブジェクトと関係の階層はありません。

アーキテクチャ/設計に関して言えば、あなたが本当に考慮しなければならないことは、ほとんど無限のトレードオフであり、これらの測定基準は同じです。何かが良いか悪いかの例を理解したい場合は、「what if」ゲームをプレイしてください。例を想像して、「Xを実行したい場合はどうしたらいいですか？答えが「たくさん」であるXには不利な点があり、答えが「実際には本当に簡単だ」というXには有利です。

一般的に言えば、疎結合：

positive：依存する何かの変化からシステムの一部を保護します（求心性結合）

否定的：関係は理解するのがより難しいかもしれません

たとえば、HTTTPに依存するシステムを開発している場合、HTTPに厳密に結合するか、緩やかに結合する必要があるかを判断します。システムが別のプロトコルに切り替わる可能性が高いと考えた場合、緩やかに結合することを選択できますが、HTTPが自分のプロトコルであると受け入れた場合、理解を簡単にするためにそのプロトコルに厳密に結合できます。

WS *の複雑さのいくつかは、プロトコルとしてのHTTPから切り離されていることを考慮してください。

求心性

何かがさまざまなもの（求心性結合の数が多い）を使用している場合、それらのいずれかが変更されると壊れやすくなります。

_{不安定性= 1}

遠心性

さまざまなもの（多数の遠心性カップリング）で何かが使用されている場合、それが変更されると、多くのものが壊れる可能性があります。

_{不安定性= 0}

安定

「安定性」のマーティンの定義は、「変更するのが難しい」と「変更する理由がほとんどない」とのエキゾチックな融合です。しかし、彼の不安定な測定基準は「変化の難しさ」のみを説明しています。「変更する理由」は、適切な抽象化レベルでインターフェイスを適切に設計する、ユーザーエンドの要件をより明確に事前に理解するなど、簡単に計算できない要因と関係があります。

そのため、求心性の低いカップリングと高い遠心性のカップリングは安定性をもたらします（多くのものを壊すので変更が難しいもののように）、反対は不安定性をもたらします（多くのものを壊さないので変更しやすいもののように） 。

多数の求心性カップリングは、デザインに焦点が合っていないことを示す指標になる可能性があります。さまざまなものを使用しているため、明確で単一の責任がない可能性があります。

多数の遠心性カップリングは、設計が広く（再）使用されていることを示すため、最初は非常に良いものと解釈される可能性があります。それでも、すべてを壊すような方法でデザインを頻繁に変更したいと思うなら、それは悪いことです。したがって、多数の遠心性カップリングを使用する場合、そのようなパッケージには「変更する理由がほとんどないか、まったくない」必要があります。設計は、変更するのが非常に難しいため、変更する理由がないという理想的な意味で安定している必要があります。

安定した抽象化の原理

依存関係の反転（当然、依存関係の注入を必要とします）やSAP（安定した抽象化の原則）などの概念はすべて、依存関係が抽象化に向かって流れることを示唆しています。また、「変更する理由がほとんどない」という文脈で「安定性」を検討する場合には、単純な理由があります。抽象インターフェースは具体的な詳細に言及せず、「物事」ではなく「何をすべきか」にのみ焦点を合わせているため、変更する理由はほとんどありません。マザーボードの加速グラフィックスポート（抽象インターフェイス）は、プラグインするGPU（具体的な詳細）よりも設計変更を受ける理由が少なくなります。

再利用性と再利用

マーティンのものといくらか衝突するものを提案できる場合、私自身の個人的な種類のメトリックは、最も再利用可能なライブラリが他のコードを最小限に再利用しようとするべきであるというこの概念です。これは、不安定な状態をハード0に向かって押し出します。これは、変更する理由が最小限であるという実際的な理由だけでなく、展開が最も簡単なライブラリを促進するためでもあります。多数の異なるライブラリに依存する汎用の広く使用されているライブラリには、変更が必要な理由がたくさんあります。また、配布が難しい厄介なバンドルもあります。ここでの違いは、私の場合の「変更の理由」は実装にまで及ぶことです。これは、ライブラリの安定したバージョンをリリースしようとするライブラリ指向のビューから来ているからです。マーティンは実装を非常に別個の部分として割り引くかもしれませんが、

配布の観点から見ると、実装とインターフェースがあいまいになり、安定したライブラリまたは不安定なライブラリに対するユーザーの依存関係が生じます。インターフェイスの観点からは、インターフェイスのみが使用され、関連付けられている実装の詳細は完全に分離されています。