改めて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 🙆♂️
少しずつ「読みやすい」「直しやすい」コードを目指していきましょう ✨
最後まで読んでいただきありがとうございました！🎉
よろしければ他の記事もご覧頂けるとすごくうれしいです。
👍 いいね / 💬 コメントいただけると励みになります！