遠心性/求心性カップリングが良いか悪いか
私は今週ソフトウェアパターン試験を行っています。私たちが研究するトピックの1つは、遠心性および求心性結合です。
他の多くのタイプに依存している場合、パッケージのCe（遠心結合）が高いことを理解しています。
例えば：
class Car{
Engine engine;
Wheel wheel;
Body body;
}
このクラスは、エンジン、ホイール、ボディのタイプに依存しているため、遠心性の高い結合になります。
一方、「ホイール」タイプは、他のいくつかのパッケージ（車、飛行機、自転車）に依存している場合、高いCa（求心性結合）になります。
私たちの試験で考えられる質問の1つは、遠心性/求心性カップリングがいつ良いか悪いかです。論理的にはプログラムは、高い求心性/求心性結合の両方を持つパッケージ/クラスを必要とするため、これは私には奇妙に思えます。
高遠心性または求心性のカップリングがいつ、どこで良い/悪い例があるのですか？
よろしくお願いします！
求心性結合は、変化の必要性または可能性のためにそれが引き起こす/節約する痛みの量に関して最も簡単に評価できます。たとえば、ホイールクラスを取り上げて、他の多くのモジュールがそれを使用してさまざまな種類の車両を構築するとします。ホイールクラスが非常に安定している場合、車両にはホイールが必要であり、信頼性の高いホイールを使用しているため、この求心性カップリングは有益です。一方、メンテナンスに関してホイールクラスが揮発性である場合、多くのコードに破壊的な変更を繰り返し導入すると、この求心性のあるカップリングが問題になります。
遠心性カップリングの概念は似ていますが、少し異なる価値命題を見ることになります。多くの個々のパーツに直接依存する車のクラスがある場合（「エンジン」と「シャーシ」だけではなく、他のサブパーツで構成される）、クラスはおそらく多くのことを行うため、メンテナンスのボトルネック。そのクラスへの変更は、その複雑さのために困難でリスクが高い可能性があります。一方、遠心性結合が高いが、実際にはかなりまとまりがあり、明確である場合、心配するオブジェクトと関係の階層はありません。
アーキテクチャ/設計に関しては、本当に考慮しなければならないことは、ほぼ無限のトレードオフであり、これらのメトリックは同じです。何かが良いか悪いかの例を見つけたい場合は、「もしも」のゲームをプレイしてください。例を想像して、「Xを実行したい場合はどうすればいいですか。答えが「たくさん」であるXには不利な点があり、答えが「実際には簡単だ」となるXには利点があります。
一般的に言えば、疎結合：
ポジティブ：システムの一部を、それが依存する何かの変化から保護します（求心性結合）
negative：関係を理解するのが難しい場合があります
たとえば、HTTTPに依存するシステムを開発している場合、HTTPと密結合するか疎結合する必要があるかを判断します。システムが別のプロトコルに切り替わると思われる場合は、疎結合を選択できます。一方、HTTPが自分のプロトコルである場合は、理解を簡単にするために、そのプロトコルに密結合できます。
WS *のいくつかの複雑さは、プロトコルとしてのHTTPからの分離にあると考えてください。
求心性
何かがさまざまなもの（多数の求心性結合）を使用している場合、それらのいずれかが変更されると、壊れる可能性があります。
不安定性= 1
有効
何かがさまざまなもの（多数の遠心性カップリング）によって使用されている場合、それが変更されると、多くのものが壊れる可能性があります。
不安定性= 0
安定性
マーティンの「安定性」の定義は、「変更するのが難しい」と「変更する理由がほとんどない」の間のエキゾチックなブレンドです。それでも、彼の不安定性の指標は「変化の難しさ」のみを説明しています。 「変更の理由」は、適切に抽象化された適切なレベルでインターフェースを適切に設計し、ユーザーエンドの要件を前もって明確に理解するなど、簡単に計算できない要因と関係があります。
したがって、遠心性の高いカップリングと遠心性の高いカップリングは安定性を生み出します（何かを壊すので変更が難しいもののように）反対に不安定性を生み出します（ものを壊さないので変更が簡単なもののように） 。
多数の求心性カップリングは、デザインにフォーカスがないことを示す指標になる可能性があります。それは、さまざまな要素をすべて使用しているため、明確で単一の責任が欠けている可能性があります。
多くの遠心性カップリングは、設計が広く（再）使用されていることを示しているため、最初は本当に良いものと解釈できます。それでも、すべてを壊すような方法でデザインを頻繁に変更したいと思うなら、それは悪いことです。したがって、多数の遠心性カップリングでは、そのようなパッケージを「変更する理由がほとんどないか、まったくない」必要があります。デザインは変更するのが非常に難しいため、変更する理由がないという理想的な意味で安定している必要があります。
安定した抽象化の原則
依存関係の逆転（当然、依存関係の注入を必要とする）やSAP（安定した抽象化の原則）などの概念はすべて、依存関係が抽象化に向かって流れることを示唆しています。また、「変更する理由がほとんどない」という文脈で「安定性」を検討する場合、単純な理由があります。抽象インターフェースは具体的な詳細については言及せず、「ものは何か」ではなく「何をすべきか」に焦点を当てているため、変更する理由が少なくなります。私たちのマザーボードのアクセラレートされたグラフィックスポート（抽象的なインターフェイス）は、それに差し込まれるGPU（具体的な詳細）よりも設計変更を受ける理由が少ないです。
再利用性と再利用
マーティンのそれと多少衝突するものを提案できるなら、私自身の個人的な種類のメトリックは、最も再利用可能なライブラリが他のコードを最小限に再利用することを求めるべきであるというこの概念です。これは、不安定さをハード0に向かって押し上げます。これは、変更する最小限の理由があるという実際的な理由のためだけでなく、デプロイする最も簡単なライブラリを促進するためでもあります。 12の異なるライブラリに依存する汎用の広く使用されているライブラリには、変更が必要な多くの理由があるだけでなく、配布が難しく、ぎこちなくバンドルされているディストリビューションもあります。ここでの違いは、私の場合、「変更する理由」は実装にも及ぶということです。これは、ライブラリの安定したバージョンをリリースしようとするライブラリ指向のビューからのものだからです。マーティンは、実装を非常に別個の部分として割り引き、ライブラリのインターフェースに関連するメトリック（その実装よりもはるかに安定している可能性があります）のみを考慮します。
配布の観点から見ると、実装とインターフェースがぼやけているため、安定したライブラリや不安定なライブラリにユーザーの依存関係が生じます。インターフェースの観点からは、インターフェースのみが使用され、関連する実装の詳細は完全に独立しています。