変更のための設計:オブジェクト指向システムにおける結合と凝集

結合と凝集は、ソフトウェアエンジニアリングでよく誤解される2つの用語です。これらは、システムのモジュール性の定性分析を示すために使用される用語であり、オブジェクト指向システムの設計の複雑さを識別および測定するのに役立ちます。

ただし、スケーラブルで管理しやすく、時間の経過とともに拡張できるシステムを構築するには、両方についての十分な知識が必要です。この投稿では、これらの両方について説明します。このトピックに関する今後の投稿で、コード例を紹介します。

凝集力と結合度はどのように異なりますか?概念の凝集度と結合度は、ソフトウェア設計の良し悪しにどのように関連していますか?凝集度と結合度、およびそれらがソフトウェア設計に与える影響について説明する前に、これらの各概念とそのタイプを理解しましょう。

カップリング

結合は、ソフトウェアモジュール間に存在する相互依存の程度、およびそれらが互いにどの程度密接に接続されているかとして定義できます。本質的に、結合はソフトウェアモジュール間の相互接続の強さを示します。この結合が高い場合、ソフトウェアモジュールは相互に依存している、つまり、他のモジュールがないと機能できないと見なすことができます。カップリングにはいくつかの側面があります。

  • コンテンツカップリング-これは、特定のモジュールが他のモジュールのコンテンツにアクセスまたは変更できるタイプのカップリングです。本質的に、コンポーネントが他のコンポーネントのアクティビティを制御するためにパラメータを渡す場合、2つのコンポーネント間に制御結合があります。
  • 共通結合-これは、共有グローバルデータにアクセスできる複数のモジュールがあるタイプの結合です。
  • スタンプ結合-これは、データ構造を使用してシステム内の1つのコンポーネントから別のコンポーネントに情報を渡すタイプの結合です。
  • 制御カップリング-これは、あるモジュールが別のモジュールの実行フローを変更できるタイプのカップリングです。
  • データ結合-このタイプの結合では、2つのモジュールがデータを交換またはパラメーターとして渡すことによって相互作用します

凝集

凝集度は、ソフトウェアモジュールの要素間の内部依存性のレベルを示します。言い換えると、凝集度は、単一のモジュールまたはコンポーネントの責任が意味のある単位を形成する程度の尺度です。凝集力には次のタイプがあります。

  • 偶発的な凝集-これは、モジュールをより小さなモジュールに分割した結果である可能性がある、計画外のランダムな凝集です。
  • 論理的凝集度-これは、論理的に関連する複数の関数またはデータ要素が同じコンポーネントに配置される凝集度の一種です。
  • 時間的凝集度-これは、モジュールの要素が同じ時点で処理される方法でグループ化される一種の凝集度です。例として、オブジェクトのセットを初期化するために使用されるコンポーネントがあります。
  • 手続き的凝集度-これは、コンポーネント内の機能が順番に実行され、手続き型凝集度になるようにグループ化された一種の凝集度です。
  • 通信の凝集度-このタイプの凝集度では、モジュールの要素は、順番に実行され、同じデータで機能するように論理的にグループ化されます。
  • シーケンシャル凝集度-このタイプの凝集度では、モジュールの要素は、そのうちの1つの出力が次の入力になるようにグループ化されます-それらはすべて順次実行されます。本質的に、コンポーネントのある部分の出力が別の部分の入力である場合、コンポーネントは順次凝集度を持っていると言います。
  • 機能的凝集度-これは、凝集度が最も高い、最良かつ最も好ましいタイプの凝集度です。このタイプの結束では、モジュールの要素は機能的に論理ユニットにグループ化され、論理ユニットとして連携して機能します。これにより、柔軟性と再利用性も向上します。

ベストプラクティス

密結合は困難であり、1つのコンポーネントへの変更は、それに接続されている他のすべてのコンポーネントに影響を与えるため、メンテナンスコストが増加します。そのため、機能が損なわれないように、接続チェーン内の他のすべてのコンポーネントをリファクタリングする必要があるため、コードのリファクタリングは困難になります。このプロセスは面倒で、多くの面倒な労力と時間がかかります。 

インスタンス変数の数が少ないクラスを設計する必要があります。つまり、インスタンス変数の数が少ない場合、クラスの設計は「適切」です。理想的には、クラス内の各メソッドは、これらのインスタンス変数の1つ以上を操作する必要があります。理論的には、クラスの各インスタンス変数がそのクラスの各メソッドによって使用または操作される場合、クラスは最大限にまとまりがあります。クラスのまとまりが高い場合、クラスのメソッドとデータメンバーは相互に依存し、単一の論理ユニットとして連携します。ただし、実際にはそのようなクラスを設計することは不可能であり、むしろ、最大限にまとまりのあるクラスを設計することはお勧めできません。