アーロンのその記事は理解に非常に役立ちます。また、マニング出版 Spring in Action 本を読むことをお勧めします。春はその問題をどのように解決するかについて非常に良い例を示し、それは間違いなくあなたの理解を改善しますこれの。
編集：
私は、テストにガイドされたGrowingオブジェクト指向ソフトウェアと呼ばれるこの素晴らしい本でこれに出くわしました。
カップリング：
一方の変更が他方の変更を強制する場合、要素は結合されます。たとえば、2つのクラスが共通の親から継承する場合、一方のクラスを変更するには、もう一方のクラスを変更する必要があります。コンボオーディオシステムについて考えてみましょう。アナログラジオからデジタルラジオに変更する場合は、システム全体を再構築する必要があるため、密結合です。システムを個別に組み立てると、カップリングが低くなり、レシーバーを交換するだけで済みます。 「ゆるく」結合された機能（つまり、結合が低いもの）は、保守が容易です。
凝集度：
要素の凝集度は、その責任が意味のある単位を形成するかどうかの尺度です。たとえば、日付とURLの両方を解析するクラスは、関連のない概念であるため、一貫性がありません。衣服と皿の両方を洗う機械を考えてみてください。両方ともうまくいくとは考えられません。2極端な場合、URLの句読点のみを解析するクラスは、概念全体を表していないため一貫性がありそうにありません。プログラマーは、何かを行うために、プロトコル、ホスト、リソースなどの他のパーサーを見つける必要があります。 「高い」一貫性を備えた機能は、保守が容易です。
凝集度-クラス/メソッドは1つのことだけに責任があるという原則に関連しています。つまり、カプセル化に属さない浮遊メソッドはありません。メソッドは1つのことだけを行います。高/低凝集は、これが保持される程度です。
カップリング-システムの異なる部分の相互依存関係。例：依存関係がある方法と場所。 2つのクラスが互いのメソッドを呼び出す場合、一方を変更すると他方を変更する必要があるため、それらは密結合されています。デカップリングとは、緊密に結合されていないもの、またはまったく結合されていないものを作成するプロセスです。
柔軟なシステムには、高い凝集力と緩い結合があります。
カップリングについては、 このウィキペディアの記事 がすべての質問に答えるはずです。 この記事 凝集力を扱います。
「デカップリング」は「リトル/ローカップリング」の単なる別名です。
したがって、これらの用語はこれらの質問に答えます。
- プロジェクトの各部分が他の部分にどの程度依存していますか？
- プロジェクトの一部だけを使用したい場合（特定の問題を解決する場合など）、プロジェクトの残りの部分についてどれだけ知る必要がありますか？
- プロジェクトのすべての部分が特定の問題に対する単一のソリューションに焦点を合わせているのか、それとも他の部分のソリューションが「漏れる」のか。
ここに結束に関する私の考えがあります。モジュールがあると想像してください。そのモジュール内には、いくつかのタスクがあります。これらのタスクが互いに非常に関連している場合、高い凝集性があると言います。これらのタスクが関連していない場合、凝集度が低いと言います。デカップリングを説明する私の最善の試みは、デカップリングがカップリングを除去する行為であるということです。
低結合は、高い凝集力を得るのに役立ちます！モジュールに関連するタスクと1つの単一の責任を持たせることを忘れないでください。しかし、カップリングとは何ですか？カップリングとは、そのモジュールに対する単一の責任を達成するための他のモジュールへの依存度です。したがって、低結合によって、外部モジュールにあまり依存していないと言っているため、高い凝集力があります。
ただし、外部モジュールに多くの依存関係がある場合、結合度が高く凝集度が低くなります。それを得る？
他の装飾された思想家やグループは言う：
凝集度とは、単一のモジュールによって実行されるタスクが機能的に関連する度合いのことです。」IEEE、1983年モジュールのコンポーネント要素間の関連付けのタイプと考えることができます。一般的に、可能な限り最高レベルの結束を望みます。」Bergland、1981
ソフトウェアコンポーネントは、そのユニット内の要素が高度な機能的関連性を示す場合、高度な凝集性を示すと言われています。これは、プログラムユニットの各要素がそのユニットが目的を達成するために不可欠であることを意味します。サマービル、1989