凝集度と結合度の違い｜高凝集・低結合が望ましい理由と判断方法

はじめに

凝集度と結合度は、どちらもクラスやモジュールなどの設計単位を評価する考え方です。しかし、凝集度は設計単位の内部、結合度はほかの設計単位との関係を評価するため、確認する対象が異なります。

内部の役割がまとまっていても、外部の実装方法へ強く依存していることがあります。反対に、外部への依存が少なくても、内部に異なる目的の処理が混在していることがあります。

本記事では、凝集度と結合度の違い、4つの組み合わせ、高凝集・低結合が望ましい理由、実務での判断方法を解説します。

凝集度は設計単位の内部を、結合度は設計単位と外部との関係を評価します。

凝集度が高い設計単位は、内部の処理やデータが共通する目的にまとまっています。詳しい定義や判断方法は、凝集度とは？高い・低いの違いと設計への影響をわかりやすく解説で説明しています。

結合度が低い設計単位は、依存先の実装方法を必要以上に知らず、公開された役割や必要な情報だけを使って連携します。詳しい定義や依存の種類は、結合度とは？高い・低いの違いと設計への影響をわかりやすく解説で説明しています。

凝集度が高ければ、結合度も低くなるとは限りません。内部の目的が明確でも外部の詳細へ依存していれば高凝集・高結合となり、外部への依存が少なくても内部に複数の目的が混在していれば低凝集・低結合となります。

二つの指標を組み合わせると、設計上の問題が内部と外部のどちらにあるのかを整理できます。

状態	判断	主な問題・対応
高凝集・低結合	目的が明確で、外部の詳細へ依存していない	変更箇所と影響範囲を限定しやすい
高凝集・高結合	目的は明確だが、外部の詳細へ依存している	外部との境界を見直す
低凝集・低結合	外部の詳細へは依存していないが、内部に複数の目的がある	内部の責務を整理する
低凝集・高結合	内部に複数の目的があり、外部の詳細にも依存している	責務と依存関係の両方を見直す

この分類は設計を数値で採点するものではありません。問題の場所と改善する方向を整理するための判断枠組みです。

高凝集・低結合が望ましいのは、変更する場所と、その変更が影響する範囲を限定しやすくなるためです。

凝集度が高ければ、同じ目的や変更理由を持つ処理が一つの設計単位にまとまります。結合度が低ければ、その設計単位で発生した変更が、ほかの設計単位へ波及しにくくなります。

高凝集は変更箇所をまとめ、低結合は変更の波及を抑えます。

ただし、低結合は依存関係をなくすことではありません。システムを動かすために必要な依存を残しながら、相手の実現方法へ必要以上に依存しない状態を目指します。

注文完了までの流れを管理するOrderServiceを例に考えます。注文処理は、保存、在庫確保、通知、請求など複数の部品と連携しますが、複数の部品を呼び出すこと自体は問題ではありません。

確認すべきなのは、OrderServiceの目的が明確か、連携先の詳細をどこまで知っているかです。

状態	`OrderService`の設計例
高凝集・低結合	注文完了までの流れを調整し、保存や通知は公開された操作を通じて依頼する
高凝集・高結合	注文完了までの調整だけを担当するが、テーブル構造や通知API固有の型へ依存する
低凝集・低結合	注文処理に加えて売上集計や請求書のレイアウトも担当するが、外部とは公開された操作で連携する
低凝集・高結合	注文、集計、請求書作成を担当し、SQLや通知APIの操作方法も直接扱う

注文完了までの調整だけを担当し、保存方法や通知方法を知らずに必要な処理を依頼していれば、高凝集・低結合と判断できます。

売上集計や請求書のレイアウト変更まで同じクラスが担当していれば、内部に異なる変更理由が混在しています。さらにSQLや通知APIの詳細まで知っていれば、内部と外部の両方に問題があります。