凝集と結合
はじめに
凝集と結合は、ソフトウェア設計におけるモジュールの品質を評価するための重要な指標です。
理想的なソフトウェア設計では、「高凝集・低結合」の状態を目指すべきとされています。
高凝集・低結合を目指す目的
ソフトウェア設計の理解の向上
凝集と結合の概念を理解することで、ソフトウェアの設計においてモジュールの責務と依存関係を適切に管理する方法を学ぶことができます。
これにより、コードの可読性やメンテナンス性が向上します。
設計の質の向上
-
高凝集
- モジュールが1つの明確な責務に集中することで、
コードの理解と管理が容易になります。 - 高凝集な設計は、システムの
拡張性や再利用性を高めます。
- モジュールが1つの明確な責務に集中することで、
-
低結合
- モジュール間の依存関係を最小限にすることで、システム全体の
変更やメンテナンスが容易になります。 - 低結合な設計は、モジュールの独立性を高め、
変更の影響を局所化することができます。
- モジュール間の依存関係を最小限にすることで、システム全体の
ソフトウェアの保守性の向上
高凝集・低結合な設計にすることで、コードの変更が他の部分に波及するリスクを減らし、保守作業を効率化できます。
これにより、バグの修正や機能の追加がスムーズに行えます。
ソフトウェアの品質向上
高凝集・低結合な設計は、ソフトウェアの品質を高めるための基本的な要素です。
設計の良し悪しがソフトウェアの安定性、パフォーマンス、使いやすさに直接影響します。
コードの再利用性の向上
高凝集なモジュールは特定の機能に特化しているため、他のプロジェクトやシステムで再利用しやすくなります。
低結合な設計は、モジュールを独立して使用することを可能にし、再利用の幅を広げます。
チームの効率化
明確なモジュール設計により、チームメンバーが各自の担当部分に集中でき、作業の重複やミスを防ぐことができます。
また、モジュール間の依存関係が管理しやすくなり、チーム全体の作業が効率化されます。
凝集(Cohesion)
凝集とは？
凝集とは、モジュール内の要素（例えば、クラスやメソッド）がどれだけ密接に関連し、共通の目的を持っているかを表す概念です。
高い凝集度を持つモジュールは、1つの明確な責務を持ち、その内部の要素がその責務に専念しています。
これにより、モジュールの理解が容易になり、変更や再利用がしやすくなります。
例:
高い凝集度のクラスは、特定のタスクに関連するメソッドとデータのみを持ちます。
例えば、ユーザー情報を扱うクラスがユーザーのデータを管理するメソッドだけを持つ場合、凝集度が高いと言えます。
凝集の種類
※高レベルの方が凝集度が高い状態
| レベル | 種類 | 説明 |
|---|---|---|
| 1 | 偶発的凝集 (Coincidental Cohesion) | 最も低い凝集度で、モジュール内の要素がランダムに集められた状態です。 これらの要素は関連性がなく、一緒に存在する理由が明確でないため、理解しづらくメンテナンスも困難です。 |
| 2 | 論理的凝集 (Logical Cohesion) | 論理的に関連する要素が集められていますが、それらは実際には異なるタスクを行います。 例えば、異なる種類のエラーハンドリングコードが一つのモジュールに集められている場合です。 |
| 3 | 時間的凝集 (Temporal Cohesion) | 特定の時間に実行される要素がまとめられた状態です。 例えば、プログラムの初期化処理やクリーンアップ処理が一つのモジュールにまとめられる場合です。 |
| 4 | 手順的凝集 (Procedural Cohesion) | 一連の手順を実行する要素が集められた状態です。 これらの要素は順序を持つ必要がありますが、全てが同じタスクに関連しているわけではありません。 |
| 5 | 通信的凝集 (Communicational Cohesion) | 同じデータを扱う要素が集められた状態です。 データに関する操作が一つのモジュールに集められている場合です。 |
| 6 | 逐次的凝集 (Sequential Cohesion) | 出力が次の要素の入力となる要素が集められた状態です。 例えば、データ処理のパイプラインがこのタイプに当たります。 |
| 7 | 機能的凝集 (Functional Cohesion) | 最も高い凝集度で、モジュールが1つの明確なタスクを実行するための要素だけを持つ状態です。 例えば、特定の計算を行う関数が機能的凝集を持つと言えます。 |
高凝集のメリット
- 理解しやすい
- 高凝集なモジュールは、1つの明確な責務に集中しているため、その内部のロジックが単純で理解しやすいです。
- これにより、新しい開発者やチームメンバーがコードを把握する際に役立ちます。
- メンテナンスの容易さ
- モジュールの責務が明確であれば、修正が必要な場合でもその範囲が明確です。
- バグの修正や機能の追加が容易になり、
影響範囲が狭くなるため、全体的なメンテナンス作業が効率的になります。
- 再利用性の向上
- 高凝集なモジュールは、特定の機能に特化しているため、他のプロジェクトやシステムで再利用しやすくなります。
- 再利用可能なモジュールは、開発の効率化とコスト削減に寄与します。
- テストの容易さ
- 高凝集なモジュールはその機能が明確であり、単体テストが行いやすいです。
- モジュールが1つの機能を持つため、テストケースが明確で、テストの精度も向上します。
結合(Coupling)
結合とは？
結合とは、モジュール間の依存関係の強さを示す概念です。
結合が強いと、1つのモジュールの変更が他のモジュールに影響を与えやすくなります。
理想的には、結合度を低く保つことで、モジュール同士が独立して動作しやすくなり、システムの変更やメンテナンスが容易になります。
例:
弱い結合（低い結合度）の場合、あるモジュールの変更が他のモジュールにほとんど影響を与えません。
例えば、ユーザーインターフェースとビジネスロジックが明確に分離されている場合、UIの変更がロジックに影響を与えることは少なくなります。
結合の種類
※高レベルの方が結合度が低い状態
| レベル | 種類 | 説明 |
|---|---|---|
| 1 | 内容結合 (Content Coupling) | 最も強い結合度で、モジュールAが直接モジュールBの内部にアクセスする状態です。 例えば、モジュールAがモジュールBの内部変数に直接アクセスする場合です。 |
| 2 | 共通結合 (Common Coupling) | モジュールが共通のデータやグローバル変数に依存している状態です。 複数のモジュールが同じグローバル変数に依存すると、変更の影響範囲が広がり、バグの発生リスクが高まります。 |
| 3 | 外部結合 (External Coupling) | モジュールが外部の共通インターフェースやフォーマットに依存している状態です。 例えば、ファイルフォーマットや通信プロトコルに依存する場合です。 |
| 4 | 制御結合 (Control Coupling) | モジュールが他のモジュールの動作を制御するために制御フラグを渡す状態です。 これは、モジュール間の依存関係が強まる原因となります。 |
| 5 | スタンプ結合 (Stamp Coupling) | モジュールがデータ構造全体を渡すが、その一部のみを使用する場合です。 これにより、モジュール間の依存関係が不必要に強まります。 |
| 6 | データ結合 (Data Coupling) | 最も弱い結合度で、モジュールがデータを単純に引数として渡し、データ構造に依存しない状態です。 例えば、関数が必要なデータのみを引数として受け取る場合です。 |
低結合のメリット
- 独立性の確保
- 低結合なモジュールは、他のモジュールとの依存関係が少ないため、変更が他の部分に与える影響が最小限に抑えられます。
- これにより、個別にモジュールを開発・修正する際に、他のモジュールへの影響を心配する必要がありません。
- 変更の容易さ
- モジュール間の結合が弱いと、1つのモジュールの変更が他のモジュールに波及しにくくなります。
- これにより、システム全体の安定性を保ちながら、柔軟に変更を加えることができます。
- テストの効率化
- 低結合な設計では、各モジュールが独立しているため、単体テストや統合テストが行いやすくなります。
- モジュールが独立しているため、テストの際に他のモジュールを模擬する必要が少なく、テストの精度が向上します。
- チームの効率化
- チームでの開発作業において、モジュール間の結合が弱いと、異なるチームメンバーが独立して作業することが容易になります。
- これにより、作業の分担がしやすく、プロジェクト全体の効率が向上します。
- スケーラビリティの向上
- 低結合な設計は、システムの拡張やスケーリングに適しています。
- 新しい機能を追加する際に、既存のモジュールに影響を与えずに追加できるため、システムの拡張性が高まります。
まとめ
高凝集・低結合を意識した設計により、モジュールの独立性が保たれ、変更やメンテナンスおよびテストが容易になります。
一方で、低凝集・高結合な設計は、システム全体が複雑化し、変更の影響が広範囲に及びやすくなります。
実際の開発においては、これらの原則を念頭に置くことで、より堅牢で柔軟なソフトウェアを設計することが可能です。
低凝集な状態のチェクリスト
チェックリスト
- 責務が複数ある
- クラスやモジュールが複数の異なる責務を持っていないか確認します。
- 一つのクラスが異なる機能やタスクを担当している場合、凝集度が低い可能性があります。
- メソッドの関連性がない
- クラス内のメソッドが互いに関連性を持たず、独立している場合、低凝集の兆候です。
- 関連するメソッドがまとまっていないと、クラスの理解が難しくなります。
- クラスの目的が不明確
- クラスの責務や目的が不明確で、クラスが何をすべきかが一目でわからない場合、低凝集の可能性があります。
- 変更が他の機能に影響を与える
- クラスのある機能に対する変更が、クラス内の他の機能に予期しない影響を与える場合、そのクラスは低凝集である可能性があります。
- 高い複雑性
- クラスが複雑で、理解やメンテナンスが困難な場合、低凝集が原因であることが考えられます。
- 多くの異なる機能が一つのクラスに詰め込まれていることが原因です。
- テストが困難
- クラスのメソッドが多くの異なる機能を含んでいるため、単体テストが困難な場合、そのクラスは低凝集である可能性があります。
- 再利用性が低い
- クラスが特定のユースケースに特化しすぎているため、再利用が難しい場合、低凝集が原因であることがあります。
- ドキュメントが不足している
- クラスやモジュールのドキュメントが不足しており、クラスの目的や機能を理解するために追加の説明が必要な場合、そのクラスは低凝集である可能性があります。
- クラスのサイズが大きい
- クラスが大きすぎて、多くのメソッドやフィールドを持っている場合、低凝集の可能性があります。
- 大きなクラスはしばしば複数の責務を持っているためです。
- 依存関係が複雑
- クラスが他のクラスやモジュールと複雑な依存関係を持ち、依存関係の管理が難しい場合、低凝集が関与している可能性があります。
改善のためのアクション
- 単一責務の原則 (SRP) に従う
- クラスが単一の責務を持つようにリファクタリングします。
- メソッドのグループ化
- 関連するメソッドをグループ化し、クラスを分割します。
- クラスの再設計
- クラスの目的が明確になるように再設計し、役割を明確にします。
- モジュールの分割
- 大きなクラスやモジュールをより小さく、関心ごとに分割します。
高結合な状態のチェックリスト
チェックリスト
- クラス間の依存関係が強い
- クラスやモジュールが他のクラスやモジュールに強く依存している場合、結合度が高い可能性があります。
- 依存先のクラスやモジュールが変更されると、依存元も変更が必要になることがあります。
- 多くのインターフェースや抽象クラスに依存していない
- 実装クラスが具体的な実装に直接依存しており、インターフェースや抽象クラスを通じて依存関係を抽象化していない場合、結合度が高くなります。
- 共有データが多い
- 複数のクラスやモジュールが同じデータを直接操作している場合、結合度が高いです。
- データの変更が他の部分に予期しない影響を与える可能性があります。
- クラスが多くの他のクラスにアクセスする
- クラスが多くの他のクラスに直接アクセスし、それらのクラスの内部に対して操作を行っている場合、結合度が高いです。
- テストが難しい
- 単体テストを行う際に、クラスやモジュールを単独でテストすることが困難で、他のクラスやモジュールとセットでないとテストできない場合、結合度が高い可能性があります。
- コードの変更が多くの場所に影響を与える
- コードの一部を変更するだけで、多くの他の部分に影響を与える場合、結合度が高いです。
- 変更が広範囲にわたる場合、そのクラスやモジュールは高結合です。
- 依存関係の管理が困難
- クラスやモジュールの依存関係が複雑で、依存関係の管理や把握が困難な場合、高結合が原因であることがあります。
- ドキュメントに依存関係が明示されていない
- クラスやモジュール間の依存関係がドキュメントに明示されておらず、コードを見ただけでは依存関係がわからない場合、結合度が高い可能性があります。
- 複雑な相互作用が存在する
- クラスやモジュールが複雑な相互作用を持ち、互いに密に絡み合っている場合、高結合の兆候です。
- 変更による副作用が大きい
- 一部の変更が、他の部分に大きな副作用を引き起こす場合、高結合が原因です。
- クラスやモジュールが互いに依存し合い、影響を与え合っています。
改善のためのアクション
- インターフェースを使用する
- クラスやモジュール間の依存関係をインターフェースや抽象クラスで抽象化し、実装から分離します。
- 依存性注入 (DI) を利用する
- 依存性注入を使用して、クラスやモジュールが直接依存せずに外部から依存性を提供します。
- モジュールの分割
- 大きなクラスやモジュールを小さく分割し、責務ごとに整理します。
- 依存関係の明示化
- ドキュメントや設計図を使って、クラスやモジュール間の依存関係を明示化し、管理しやすくします。
- 変更の影響を最小化する
- 変更が他の部分に影響を与えないように設計し、変更が局所的に留まるようにします。
Discussion