SOLID 原則（ソリッドゲンソク）

2025年11月7日

SOLID 原則（ソリッドゲンソク）

英語表記: SOLID Principles

概要

SOLID原則は、オブジェクト指向プログラミング（OOP）の文脈において、ソフトウェアの設計品質を向上させるために提唱された、五つの基本原則の頭文字を組み合わせた用語です。この原則群は、システムを柔軟で、理解しやすく、そして最も重要な点として「保守しやすい」状態に保つための「設計手法」として機能します。特に大規模開発や長期運用が前提となるプロジェクトで、コードの拡張性（変更の容易さ）と再利用性を高めるために不可欠な指針となっております。

この原則は、プログラミングパラダイムの中でも特に「オブジェクト指向プログラミング」の設計手法に分類され、クラスやインターフェースといったOOP特有の要素をどのように構成すべきかを定めています。

詳細解説

SOLID原則は、著名なソフトウェアエンジニアであるロバート・C・マーティン氏（通称Uncle Bob）によって体系化されました。オブジェクト指向プログラミングでは、クラスやオブジェクトを用いて現実世界をモデル化し、カプセル化や継承、ポリモーフィズムといった仕組みを使って複雑な問題を解決しようとします。しかし、これらの強力な仕組みを誤って使用すると、かえってコードが複雑化し、変更を加えるたびに予期せぬバグが発生する「脆い（もろい）」システムになりがちです。

SOLID原則は、このような「設計の腐敗」を防ぎ、OOPのメリットを最大限に引き出すための具体的なガイドラインを提供します。これは、オブジェクト指向設計における「設計手法」の最高峰の一つだと私は感じています。

5つの原則とその役割

SOLIDは以下の5つの原則の頭文字から構成されています。

S: 単一責任の原則 (Single Responsibility Principle, SRP)

内容: クラスが持つべき責任（変更の理由）は、ただ一つであるべきだ、という原則です。
目的: 一つのクラスに複数の役割を持たせると、ある役割に関する変更が、全く関係のない別の役割に影響を与えるリスクが発生します。SRPを遵守することで、クラスの凝集度が高まり、保守性が飛躍的に向上します。設計において、クラスを「何でも屋」にするのではなく、「専門家」にすることが、美しいコードへの第一歩です。

O: 開放/閉鎖の原則 (Open/Closed Principle, OCP)

内容: ソフトウェアの構成要素（クラスなど）は、拡張に対しては「開放」され、修正に対しては「閉鎖」されるべきだ、という原則です。
目的: 新しい機能を追加する際、既存の安定して動作しているコードを修正する必要がないように設計します。これは、インターフェースや抽象クラスを用いて、変更の対象を新しい拡張部分だけに限定することで実現されます。既存コードに手を加えずに機能を追加できる設計は、システムの安定性を保つ上で非常に重要です。

L: リスコフの置換原則 (Liskov Substitution Principle, LSP)

内容: 派生クラス（サブクラス）は、基本クラス（スーパークラス）と置き換え可能でなければならない、という原則です。
目的: この原則は、継承関係の健全性を保証します。もし子クラスが親クラスの振る舞いを予期せぬ形で変更してしまうと、親クラスの型を参照しているコードが正しく動作しなくなります。これは、継承というオブジェクト指向の強力な機能を使う上での「暗黙のルール」だと理解しておくと良いでしょう。

I: インターフェース分離の原則 (Interface Segregation Principle, ISP)

内容: クライアント（利用者）に、必要としないメソッドを持つ巨大なインターフェース（Fat Interface）の実装を強制してはならない、という原則です。
目的: インターフェースを細かく分割し、利用者が本当に必要な機能（メソッド）だけを参照できるようにします。これにより、クラス間の依存関係が最小限に抑えられ、疎結合なシステムを構築できます。これはSRPがクラスの粒度を扱うのに対し、ISPはインターフェースの粒度を扱うものだと考えると理解しやすいです。

D: 依存性逆転の原則 (Dependency Inversion Principle, DIP)

内容: 上位レベルのモジュールは、下位レベルのモジュールに依存してはならず、両方とも抽象（インターフェースや抽象クラス）に依存すべきである、という原則です。
目的: 具体的な実装（詳細）ではなく、抽象的な契約（インターフェース）に依存することで、モジュール間の結合度を大幅に下げます。例えば、ビジネスロジック（上位）がデータベースの実装（下位）に直接依存するのではなく、データアクセスインターフェース（抽象）に依存するように設計します。これにより、データベースを変更してもビジネスロジックに影響が出ない、柔軟でテストしやすいシステムが実現します。

これらの原則は、オブジェクト指向プログラミングにおける「設計手法」として、コードの構造を決定づける上で極めて重要な役割を果たしています。

具体例・活用シーン

SOLID原則は抽象的な概念に聞こえますが、身近な例に置き換えると、なぜ設計が重要なのかがよくわかります。ここでは、特に初心者が理解しやすいように、「自動車整備工場」を舞台にした比喩で説明します。

自動車整備工場（システム）の設計を考えてみましょう。この工場は、車の修理や点検、洗車といったサービスを提供しています。

S: 単一責任の原則（SRP）の適用

もし、一人の整備士（Mechanicクラス）が、エンジンの修理、オイル交換、顧客への請求書作成、部品の発注をすべて担当していたとします。

問題点: 請求書のフォーマットが変わっただけで、エンジン修理のロジックまで影響を受ける可能性があります。この整備士は多忙で、ミスも増えがちです。
SRP適用後:
- 修理担当者（RepairEngineクラス）：修理のみを担当。
- 会計担当者（BillingServiceクラス）：請求書作成のみを担当。
- 部品発注担当者（PartsOrdererクラス）：発注のみを担当。