第5章 低凝集 ─バラバラになったモノたち─
凝集度とは
凝集度とは、モジュール内におけるデータとロジックの関係性の強さを表す指標である。
本章では、モジュールの粒度を「クラス」とし、高凝集な設計を目指す。
- 高凝集：変更に強い
- 低凝集：壊れやすく、変更が困難
5.1 staticメソッドの誤用
問題点
- static メソッドとデータクラスがセットで登場しがち
- データのみを持つクラスと、処理のみをするクラスに分かれる
- static をつけていないだけのインスタンス変数にも注意
- とりあえず static をつけてエラーが出るかどうかで static メソッドか判断可能
- static メソッドは低凝集になりやすい
解決策
- インスタンス変数とその変数を用いるロジックを同じクラスに実装する
- static はログ出力やフォーマット変換など、凝集度に無関係なものに限定する
5.2 初期化ロジックの分散
問題点
- コンストラクタを公開すると初期化メソッドが分散しがち
解決策
- private constructor + factory method で目的別に初期化する
- 生成ロジックが増えすぎた場合は factory class を検討する
5.3 共通処理クラス（Common・Util）
問題点
- common や util クラスは static の問題を抱える
- static の使用で低凝集構造になる
- グローバル変数が出現しやすくなる
- 無関係な共通処理が雑多に置かれる
解決策
- 安易に共通処理クラスを作らず、Value Object を活用する
- 横断的関心事（ログ出力・例外処理など）は共通処理としてまとめても良い
5.4 結果を返すために引数を使わない
問題点
- 出力引数を使用すると、入力か出力か判別が難しくなる
- メソッド内部のロジックを確認しないと動作を理解できない
解決策
- 出力引数は極力使わない
- 複数の値を返したい場合は Value Object を作成する
5.5 多すぎる引数
問題点
- 引数が増えると、処理が肥大化し、低凝集につながる
- プリミティブ型執着：プリミティブ型を乱用すると重複コードや無秩序なロジックが生まれる
解決策
- クラスの量産を恐れず、概念的に意味のあるクラス（Value Object）を作る
- 引数を持つデータは、適切なクラスにまとめる
5.6 メソッドチェイン
問題点
- クラスの奥深い要素にアクセスしやすくなる
- 仕様変更やバグの影響を調べる範囲が広がる
解決策
- インスタンス変数は private にし、メソッド経由で制御する
-
"尋ねるな、命じろ" の設計を意識する
- 例：インスタンス変数を直接見るのではなく、メソッドを通じて適切な処理を行う
まとめ
本章では、低凝集な設計を避けるためのポイントを解説した。
低凝集を防ぎ、保守性の高い設計を目指すために、以下を意識する：
- static method は極力減らす
- 初期化ロジックは factory method で統一
- common / util class の乱立を防ぐ
- 出力引数は使わない
- 多すぎる引数は Value Object にまとめる
- メソッドチェインは極力避ける
方針
高凝集な設計を心がけることで、コードの変更耐性を向上させ、保守しやすくする。
特に、データとロジックの適切な結びつきを意識し、設計の一貫性を保つことが重要である。
設計が難しいと感じる場合は、チームメンバーと相談しながら進めるのが望ましい。