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

あなたが小さなカフェを経営しているとします。最初は一人でコーヒーを淹れ、会計をし、掃除までこなしています。最初のうちは問題ありません。

しかし、少しずつお客さんが増えてきて、忙しくなります。注文を取りながらお釣りを計算し、掃除もしなければならない。結果としてミスが増え、どれも中途半端になってしまいました。

この状況は、ひとつのクラスに複数の責任を持たせているのと同じです。役割を分けて、「バリスタ」「レジ係」「清掃スタッフ」と責任を分担すれば、それぞれが自分の仕事に集中でき、お店全体もスムーズに回ります。これが単一責任の原則です。

2. Open/Closed Principle（開放/閉鎖の原則）

あなたのカフェでは、季節ごとに特別メニューを提供しています。春は「桜ラテ」、夏は「アイスコーヒー」などです。

ところが、メニューを増やすたびに古いメニュー表を印刷し直し、価格計算のルールも書き換えなければなりません。そのたびに混乱が起きます。

そこで、「季節ごとのメニューを追加できるように」仕組みを変えました。新しいメニューを登録するだけで反映されるようにしたのです。既存のメニュー表を壊さずに、新しい内容を“追加”できるようになりました。

これが「変更に閉じ、拡張に開かれている」状態です。つまり、今ある仕組みを壊さずに新しい機能を増やせる設計が理想です。

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

配達サービスを考えてみましょう。普通の配達員は自転車で荷物を届けますが、冷凍品を扱う「冷凍配達員」もいます。

冷凍配達員を通常の配達員として扱ってしまうと、「冷凍品を常温で届けてしまう」などのトラブルが起きます。つまり、見た目は似ていても、同じ使い方をしてはいけない場合があるのです。

この原則は「上位の型（親クラス）を置き換えても動作が壊れないこと」を求めています。つまり、同じ“配達員”でも、冷凍品用・通常用を区別して扱う設計にすれば、安全で正しい振る舞いが保証されます。

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

あなたが家電メーカーの開発担当だとします。新しい多機能プリンタを作りました。印刷もスキャンもFAXもできるモデルです。

ところが、小さなオフィスでは「印刷しか使わない」顧客もいます。それなのに、スキャン機能やFAX機能の設定もしないと使えない構造になっていたら、ユーザーは不便に感じるでしょう。

そこで、「印刷機能だけのシンプルモデル」「スキャン専用モデル」をそれぞれ提供するようにしました。必要な機能だけを切り出した設計です。

これがインターフェース分離の原則です。利用者が必要なものだけを使えるようにすることで、シンプルで柔軟な構造になります。

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

あなたがレストランを経営していて、特定のパン屋さんから毎朝パンを仕入れているとします。ある日、そのパン屋さんが休業してしまいました。仕入れが止まり、営業にも支障が出ます。

このように、特定の“相手”に依存してしまうと、相手が変わった時にこちらも困ります。

そこで、「パン屋から仕入れる」という具体的な仕組みに依存するのではなく、「パンを提供してくれる業者」という抽象的な契約（ルール）を決めます。これに従えば、どのパン屋でも代わりに納入できます。

これが依存性逆転の原則です。上位の仕組みが具体的な実装に依存しないことで、柔軟で変更に強い設計になります。

まとめ

- SOLID原則は、チーム開発や長期運用におけるトラブルを防ぐための基本です。
- 一見理屈っぽく感じても、実際には日常生活の中にも同じ考え方が多く存在します。
- 責任の分担、変更に強い設計、安全な置き換え、必要な機能の分離、そして柔軟な依存関係。
これらを意識することで、システムはより健全で成長しやすいものになります。