改めてSOLID原則とは

👉 「変更に強く、読みやすく、壊れにくいコードを書くための考え方」
を5つに分けて整理したものです。

1つずつ振り返っていきましょう 👇

① S：単一責任の原則（Single Responsibility Principle）🧩

🧠 何を言っている？

「クラス（または関数など）は、1つの役割だけを持とう」

📌 ポイント

「1つの理由」でしか変更されない状態が理想
役割が増えると、修正の影響範囲が広がる 😱

🌱 初心者向けイメージ

❌「ログインも、保存も、表示も全部やるクラス」
✅「ログイン担当」「保存担当」「表示担当」に分ける

👉 1クラス = 1お仕事 を意識しよう ✨

② O：オープン・クローズドの原則（Open-Closed Principle）🚪

🧠 何を言っている？

「変更には強く、追加にはやさしく」

📌 ポイント

既存のコードは なるべく変更しない
新しい機能は 追加で対応できる形 にする

🌱 初心者向けイメージ

❌ if文をどんどん追加して分岐だらけ 😵
✅ 新しいクラスを作って差し替えるだけ 😄

👉 「動いているコードを壊さずに拡張できるか？」 がカギ 🔑

③ L：リスコフ置換の原則（Liskov Substitution Principle）🔁

🧠 何を言っている？

「子クラスは、親クラスの代わりとして自然に使えるべき」

📌 ポイント

親クラスを使うコードを、子クラスに置き換えても問題が起きない
期待を裏切らない振る舞いが大事

🌱 初心者向けイメージ

「車」として使っていたものを「スポーツカー」に変えても、普通に走る 🚗💨
ブレーキが効かなくなったらアウト ❌

👉 is-a関係が本当に成り立っているか？ を考えよう 🤔

④ I：インターフェース分離の原則（Interface Segregation Principle）✂️

🧠 何を言っている？

「使わない機能に、無理やり依存させない」

📌 ポイント

大きすぎるインターフェースは分割する
必要なものだけを持たせる

🌱 初心者向けイメージ

❌ 「全部入りリモコン」を渡される 📺
✅ 「テレビ用」「エアコン用」に分かれている 🎛️

👉 クラスが「知らなくていいこと」を持っていないか？ をチェック 👀

⑤ D：依存性逆転の原則（Dependency Inversion Principle）🔄

🧠 何を言っている？

「具体ではなく、抽象に依存しよう」

📌 ポイント

クラス同士をガチガチに結びつけない
インターフェース（抽象）を間に挟む

🌱 初心者向けイメージ

❌ 「このエンジン専用の車」
✅ 「エンジンという約束ごとに依存する車」

👉 差し替え可能な設計ができる と、テストも楽になる 🧪✨

⑥ 🌈 SOLID原則全体まとめ

原則	ひとことで
S	役割は1つだけ 🧩
O	追加しやすく、壊しにくく 🚪
L	置き換えても安心 🔁
I	使う分だけ持つ ✂️
D	抽象に依存する 🔄

🎯 初心者さんへのアドバイス

最初から全部守ろうとしなくてOK 🙆‍♂️

「ちょっと役割多すぎかも？」 と気づけるだけで大きな進歩 🌱

リファクタリングの指針として使うのがベスト 👍

6. 🏁 おわりに

ここまで SOLID原則全5回、お疲れさまでした！🎉
少しでも

「設計ってこう考えればいいんだ」
「コードの見え方が変わってきたかも」
と感じてもらえたら嬉しいです 😊

SOLID原則は、
❌ 最初から完璧に守るためのルール
ではなく、
✅ コードに迷ったときの“考え方の道しるべ
のようなものです 🧭

実際の開発では、

「このクラス、ちょっと役割多くない？🤔」
「if文増えすぎてない？😵」
「ここ、差し替えづらそうだな…」

そんな違和感に気づけるだけで、大きな一歩です 🌱
それこそが SOLID原則を学んだ成果だと思います。

最初は小さなリファクタリングでOK 🙆‍♂️
少しずつ「読みやすい」「直しやすい」コードを目指していきましょう ✨

最後まで読んでいただきありがとうございました！🎉

よろしければ他の記事もご覧頂けるとすごくうれしいです。

👍 いいね / 💬 コメントいただけると励みになります！