SOLID原則 ― 良い設計の5つの指針｜Javaデザインパターン学習コース BecomeCoder

導入

デザインパターンの多くは、共通するいくつかの「設計の価値観」に沿って作られています。その代表が SOLID原則 です。パターンを学ぶ前に、この5つの指針を押さえておきましょう。

説明

SOLID は、5つの原則の頭文字を並べたものです。

記号	原則	ざっくり言うと
S	単一責任の原則（SRP）	1つのクラスは1つの役割だけを持つ
O	開放閉鎖の原則（OCP）	拡張には開き、修正には閉じる（既存を壊さず機能追加）
L	リスコフの置換原則（LSP）	親クラスは、子クラスで置き換えても正しく動く
I	インターフェース分離の原則（ISP）	使わないメソッドへの依存を強制しない。小さく分ける
D	依存性逆転の原則（DIP）	具体ではなく抽象（インターフェース）に依存する

特に重要なのが、いちばん最後の D（依存性逆転） です。たとえば「通知を送る」処理を考えます。

// ✕ 具体クラスに直接依存している
class OrderService {
    EmailSender sender = new EmailSender();   // メール送信に固定されてしまう
    void complete() { sender.send("完了しました"); }
}

これだと、SMS通知に変えたくなったとき OrderService 自体を書き換える必要があります。そこで 抽象（インターフェース） に依存させます。

interface Notifier { void notify(String message); }

class OrderService {
    Notifier notifier;                        // 「通知できる何か」に依存する
    OrderService(Notifier notifier) { this.notifier = notifier; }
    void complete() { notifier.notify("完了しました"); }
}

こうすると、Notifier を実装したクラス（メール・SMS・Slack…）を外から差し込めます。OrderService は一切変更せずに、通知手段を切り替えられるのです。この「抽象に依存させ、具体を外から注入する」考え方は、後のStrategyパターンや依存性注入（DI）、そしてSpringフレームワークの核心にそのままつながっていきます。

SOLIDは「絶対に守る規則」というより「設計に迷ったときの羅針盤」です。これから学ぶパターンが、SOLIDのどの原則を実現しているかを意識すると、理解がぐっと深まります。