凝集度とは？高い・低いの違いと設計への影響をわかりやすく解説

はじめに

一つのクラスへ処理を追加し続けると、注文登録、メール送信、売上集計、請求書作成など、目的の異なる処理が混在することがあります。

すべて注文に関係する処理であっても、役割や変更される理由が異なれば、クラスの目的は分かりにくくなります。

このようなクラスやモジュール内部のまとまりを評価する考え方が、凝集度です。

凝集度とは、一つのクラスやモジュールに含まれる処理やデータが、共通する目的にどれだけまとまっているかを表す考え方です。一つの目的を実現するために、関係する処理やデータが集まっている状態は、凝集度が高いといえます。

反対に、異なる目的を持つ処理が一か所へ集められている状態は、凝集度が低いといえます。凝集度は、クラスの大きさや処理数だけでは判断できません。複数の処理があっても、一つの目的を実現するために必要な処理であれば、まとまりのある設計です。

凝集度の高いクラスは、「何を担当するクラスか」を具体的に説明できます。

凝集度の低いクラスは、「注文に関する処理」「利用者を管理する処理」のように、広い言葉でしか説明できない傾向があります。

一つの目的に関係する処理がまとまっていれば、クラス名やモジュール名から役割を把握しやすくなります。修正する場所を探す場合も、どこに対象の処理があるか判断しやすくなります。

関連する処理がまとまっていれば、仕様変更の対象を追いやすくなります。異なる目的の処理が混在していると、一つの機能を変更するだけでも、関係のない処理を壊していないか確認しなければなりません。

役割が明確であれば、そのクラスが何を正しく行えばよいか判断できます。入力と結果の関係が一つの目的に沿っているため、テストする範囲も明確になります。

例えば、OrderManagerというクラスが、次の処理を呼び出して調整するだけでなく、それぞれの詳細な処理まで内部に持っているとします。

これらはすべて注文に関係しています。

しかし、在庫管理のルール、メールの文面、集計条件、請求書の形式は、それぞれ異なる理由で変更されます。複数の処理を順番に呼び出す調整役であること自体は、凝集度が低いとは限りません。

問題は、在庫、通知、集計、請求という異なる目的の詳細まで、同じクラスが担当していることです。目的ごとに整理すると、次のようになります。

分割の目的は、クラス数を増やすことではありません。

異なる目的を分け、それぞれが何を担当するのか明確にすることです。
クラスの責務が曖昧になる背景については、責務が曖昧なクラスはなぜ生まれるのかで説明しています。

「このクラスは何をするものか」を、具体的な一文で説明できるか確認します。
「さまざまな処理を管理する」のような説明しかできない場合は、複数の目的が混在している可能性があります。

処理同士が、一つの目的を実現するために協調しているか確認します。同じ業務分野に関係しているだけでは、十分なまとまりとはいえません。

クラス内の処理が、共通するデータや状態を利用しているか確認します。一部の処理でしか使用しないデータが増えている場合は、別の役割が混ざっている可能性があります。

一つの仕様変更によって、クラス内の処理が一緒に変更されるか確認します。異なる理由で個別に変更される処理が混在している場合は、分割を検討します。「同じ理由で変更されるか」は、凝集度を判断するための実務的な目安です。

変更理由を基準に、処理をまとめるか分けるか判断する考え方は、共通化とは？「とりあえず共通化」が設計を壊す理由を解説で詳しく説明しています。

ただし、四つすべてを満たすことを、機械的な合格条件とするものではありません。クラスの目的を中心に、扱うデータや変更理由を補助的な手掛かりとして判断します。

凝集度には、まとまり方による分類があります。