ソフトウェア設計原則
定義
要件を実装可能な構造に変換するプロセス。データ・アーキテクチャ・インターフェース・コンポーネントの4側面を扱う。
なぜ重要か
良い設計は変更を安く保つ。将来の要件変更に対して、できるだけ小さい変更で対応できる構造を作ることが設計の本質的な目標。設計の決定は後から変更するコストが最も高い投資である。
核心的原則
凝集度と結合度
- 凝集度は高く: モジュール内の要素が単一の目的を持つ
- 結合度は低く: モジュール間の依存を最小化する
「高凝集・低結合」が守られているほど、変更の影響範囲が小さい。
情報隠蔽
モジュールは実装の詳細を隠蔽し、インターフェースだけを公開する。内部実装を変えてもインターフェースが変わらなければ、他のモジュールに影響しない。
SOLID原則
| 原則 | 意味 | 違反した時のコスト |
|---|---|---|
| Single Responsibility | 変更理由は1つだけ | 変更が無関係な箇所を壊す |
| Open/Closed | 拡張に開き・変更に閉じる | 機能追加のたびに既存コードを書き換える |
| Liskov Substitution | 派生クラスは基底クラスと置換可能 | 継承が意図しない挙動を生む |
| Interface Segregation | 使わないメソッドへの依存を強制しない | 変更が無関係なクライアントに波及 |
| Dependency Inversion | 抽象に依存し具象に依存しない | テストが困難・モジュールの入れ替えができない |
設計のにおい（問題の兆候）
- 剛性（Rigidity）: 1つの変更が多くの変更を引き起こす
- 脆弱性（Fragility）: 変更のたびに無関係な箇所が壊れる
- 不動性（Immobility）: コードを他のプロジェクトで再利用できない
- 粘着性（Viscosity）: 正しい方法より間違った方法の方が簡単
適用場面
- モジュール・クラスの責務を決めるとき
- 変更が怖い箇所をリファクタリングするとき
- 新機能追加時にどこを変えるべきかを判断するとき
関連概念
出典
実践ソフトウェアエンジニアリング（Pressman）第11〜15章