SOLID原則（単一責任原則など）

オブジェクト指向プログラミング（OOP）におけるSOLID原則は、ソフトウェア設計において保守性、拡張性、再利用性を高めるための5つの基本原則を示しています。Robert C. Martin（通称 Uncle Bob）によって提唱されました。これらはクラス設計やアーキテクチャをより良くするためのガイドラインとして広く使用されています。

---

SOLID原則の5つの構成要素

1. 単一責任原則（Single Responsibility Principle, SRP）

• 定義: クラスはたった一つの責任しか持つべきではなく、その責任を完全にカプセル化すべきである。

• 意味: クラスに複数の理由で変更が加わる状態を避ける。

• 目的: 変更の影響範囲を最小限に抑えることで、保守性を高める。

• 例: データの読み込みと表示処理を1つのクラスに持たせず、それぞれ別のクラスに分ける。

---

2. オープン/クローズド原則（Open/Closed Principle, OCP）

• 定義: ソフトウェアの構成要素（クラス、モジュールなど）は拡張に対して開かれていなければならず、修正に対して閉じていなければならない。

• 意味: 既存のコードを変更せずに新しい振る舞いを追加できるようにする。

• 目的: 機能追加時のリスクを減らし、安全な拡張を可能にする。

• 例: 抽象クラスやインターフェースを利用して、新しい処理は派生クラスで実装する。

---

3. リスコフの置換原則（Liskov Substitution Principle, LSP）

• 定義: 派生クラスのオブジェクトは、基底クラスのオブジェクトと置き換えてもプログラムの正しさが保たれるべきである。

• 意味: サブタイプはスーパークラスの契約（仕様）を守るべきである。

• 目的: 多態性（ポリモーフィズム）を安全に利用する。

• 例: 「四角形は長方形の一種である」としても、四角形クラスで長方形の面積計算ロジックが壊れるようであればLSP違反となる。

---

4. インターフェース分離原則（Interface Segregation Principle, ISP）

• 定義: クライアント（利用側）は、使用しないメソッドへの依存を強制されるべきではない。

• 意味: 大きなインターフェースを、機能ごとに分割して小さく意味のあるインターフェースを定義すべき。

• 目的: 不要な実装の強制を防ぎ、柔軟性を高める。

• 例: 「印刷」「スキャン」「FAX」機能をそれぞれ別のインターフェースに分割する。

---

5. 依存性逆転原則（Dependency Inversion Principle, DIP）

• 定義: 高水準モジュールは低水準モジュールに依存すべきではなく、どちらも抽象に依存すべき。また、抽象は詳細に依存すべきでなく、詳細が抽象に依存すべき。

• 意味: 実装ではなくインターフェースや抽象クラスに依存する設計にする。

• 目的: モジュール間の結合度を下げ、柔軟でテストしやすい構造にする。

• 例: サービスクラスが具体的なデータベースクラスに依存せず、リポジトリインターフェースに依存する。

---

まとめ

SOLID原則を理解し実践することで、コードの拡張性・保守性・再利用性が大きく向上し、大規模なシステムでも柔軟に対応できる設計が可能になります。