読み方：ソリッドげんそく

SOLID原則【SOLID principles】

SOLID原則とは？

ソフトウェアの保守性と拡張性を高めるための設計指針を5つにまとめたもの。2000年代初頭にロバート・C・マーティン（Robert C. Martin）氏によって体系化され、各原則の頭文字をつなげて命名された。オブジェクト指向プログラミングを前提に語られることが多いが、考え方は様々なソフトウェア設計事例に通じる。

「S」は「単一責任の原則」（single-responsibility principle）で、一つのクラスや部品が担う役割を一つに絞るという考え方である。例えば、ユーザー情報の保存とメール送信を同じクラスが受け持っていると、一方を修正した際に他方へ思わぬ影響が及ぶ可能性がある。責任を明確に分離することで、変更の影響範囲を局所に抑え、不具合の混入を防ぎやすくなる。

「O」は「開放・閉鎖の原則」（open/close principle）で、既存のコードを書き換えることなく新しい機能を追加できる構造を目指す考え方である。「拡張には開いており、修正には閉じている」と表現される。すでに正常に動作している部分に手を触れず、新たなコードを付け加えることで対応できれば、既存の動作やテストへの影響を最小化できる。

「L」は「リスコフの置換原則」（Liskov substitution principle）で、親クラスを使っている箇所をサブクラスに置き換えても、プログラムが問題なく動作しなければならないという原則である。1980年代にバーバラ・リスコフ（Barbara Liskov）氏が提唱した考えに基づく。継承関係を適切に設計することで部品の互換性が保たれ、システム全体の信頼性が高まる。

「I」は「インターフェース分離の原則」（interface segregation principle）で、利用者にとって不要な機能まで含む大きなインターフェースを持たせるべきではないという考え方である。目的に応じて小さなインターフェースを複数用意し、各クラスが必要な部分だけに依存できるように整えることで、無関係な変更によって思わぬ箇所が影響を受けるリスクを減らせる。

「D」は「依存性逆転の原則」（dependency inversion principle）で、上位のモジュールが下位の具体的な実装に直接依存するのではなく、双方が何らかの抽象的な規約（インターフェースや抽象クラス）に依存するよう設計するという考え方である。具体的な実装の間に共通の約束事を挟むことで、実装の差し替えが容易になり、テストのしやすさや柔軟性が向上する。

これら5つは互いに補い合う関係にあり、組み合わせて用いることで設計全体の一貫性が保たれる。ソフトウェアの規模が大きくなるほど変更の連鎖は複雑になるが、SOLID原則はその複雑さを制御し、コードを長期にわたって扱いやすい状態に保つための基本的な枠組みである。