メインコンテンツまでスキップ

第8章：SOLID全体マップ（迷子防止）🗺️🌟

この章で「できるようになる」こと ✅✨​

  • SOLIDを5つの暗記じゃなくて、「変更に強くするための地図」として説明できる🧠🗺️
  • 目の前のコードを見て「今はどの原則を使うとラクになるか」をざっくり当てられる🎯✨
  • “やりすぎ抽象化”を避けつつ、小さく安全に設計を良くする考え方がわかる🧼🔧

Refactored Machine

SOLIDって結局なに？（超ざっくり）😊​

SOLIDはね、**「未来の変更で泣かないための5つのコツ」**だよ〜🥹✨ ポイントはこれ👇

  • ✅ 未来に変わりそうな場所を見つける
  • ✅ そこに**差し替え口（境界）**を作る
  • ✅ 依存の向きを整えて、大事なロジックを守る

つまりSOLIDは「おしゃれな設計」じゃなくて、変更コストを下げる節約術💸✨

まずこれだけ覚える：SOLID “迷子防止” 早見表 🧭✨​

SOLID Pillars

① SRP（単一責任）🌷​

一言：1つのクラス（関数）が、いろんな理由で変更されないようにする✂️ あるある痛み：

  • 「料金計算を直したら、保存が壊れた😇」 合図（ニオイ）👃：
  • 1ファイルに 計算 / 保存 / 表示 / 通知 が混ざってる まずやる一歩：
  • 「計算だけ」「保存だけ」みたいに役割で分ける🧩

② OCP（拡張に開く、修正に閉じる）🚪✨​

一言：機能追加のたびに既存コードをベタベタ直さなくて済むようにする🎁 あるある痛み：

  • クーポン種類が増えるたびに switch が肥大化して地獄😵 合図（ニオイ）👃：
  • if / switch が「種類」や「パターン」で増殖してる まずやる一歩：
  • 「差し替え口（interface）」を作って、実装を入れ替え可能にする🔁

③ LSP（リスコフの置換）🔁🧩​

一言：「その型として扱っても、動きが破綻しない」ことを守る🛡️ あるある痛み：

  • 同じ Payment なのに、ある実装だけ例外だらけで壊れる💥 合図（ニオイ）👃：
  • 子クラス/実装だけ「特別ルール」「例外」「前提条件」が増える まずやる一歩：
  • “共通で満たすべき約束”を小さくし、テストで守る✅

④ ISP（インターフェース分離）✂️😊​

一言：「使わないメソッドを持たされる」苦しみをなくす🆘 あるある痛み：

  • Notifier に sendEmail() も sendPush() も writeLog() も全部入ってる😇 合図（ニオイ）👃：
  • interfaceが太くて、実装が空メソッドだらけ まずやる一歩：
  • 役割ごとに薄く分ける（EmailNotifier / PushNotifier など）🧻✨

⑤ DIP（依存性逆転）🙅‍♀️👑​

一言：大事なロジック（上位）が、詳細（DBや外部API）に振り回されないようにする👑 あるある痛み：

  • 料金計算のテストを書きたいのに、DB接続が必要で詰む😵‍💫 合図（ニオイ）👃：
  • “重要ロジック”が、fetch() やDBやSDKを直で呼んでる まずやる一歩：
  • 上位はinterfaceに依存して、実装は外側から注入する💉✨

SOLIDを「選ぶ」ための4ステップ 🧠🗺️​

Step 1：変更点を先に書く（未来予知メモ）🔮📝​

例（Campus Café 注文アプリ☕️📦）

  • クーポンが増える🎟️
  • 支払い方法が増える💳
  • 通知方法が増える🔔
  • 料金ルールが季節で変わる🌦️
  • 保存先が変わる（local → DB → API）🗄️➡️🌍

Step 2：「理由」でグルーピングする🧺✨​

  • 料金の理由 → 計算系（SRP）
  • 種類が増える理由 → 差し替え（OCP）
  • “同じ扱い”したい理由 → 置換性（LSP）
  • 使う機能が違う理由 → 分離（ISP）
  • 詳細が変わる理由 → 逆転（DIP）

Step 3：差し替え口を小さく作る🔁🧩​

いきなり大改造しないで、最小のinterfaceからでOK🙆‍♀️✨

Step 4：テストで「約束」を固定する✅🧪​

SOLIDは“信仰”じゃなくて、テストで守る技術だよ〜🧡

ミニ実装：SOLIDの「境界」だけ先に作ってみる 🧱✨​

ここでは、まだ各原則を深掘りしないで、差し替え口の雰囲気だけ作るよ😊

// domain（大事なルール側）っぽいイメージ

export type LineItem = { name: string; price: number; qty: number };

export type Order = {
  items: LineItem[];
  couponCode?: string;
  paymentMethod: "cash" | "card";
};

export interface DiscountPolicy {
  apply(subtotal: number, couponCode?: string): number; // 割引後の金額を返す
}

export interface PaymentGateway {
  pay(amount: number): Promise<void>;
}

export interface OrderRepository {
  save(order: Order, total: number): Promise<void>;
}

「まだ中身は適当でもいいから、変わりそうなところを先に分けてる」のがポイントだよ〜🧠✨ この“差し替え口”があるだけで、後の章（SRP/OCP/DIP…）がめちゃやりやすくなる👍

ミニ課題：未来の変更をSOLIDにマッピングしよう📝✨（20分）​

次の変更が来たとして、どの原則が効きそう？って当ててみてね🎯 （※正解は1つじゃないよ〜！😊）

  1. クーポンが10種類に増える🎟️
  2. 支払いにPayPay的なものが増える💳
  3. 通知がメール＋アプリ＋Slackに増える🔔
  4. 「学割」と「雨の日割」が組み合わさる🌧️🎓
  5. 保存先がAPIになって、通信失敗も考慮したい🌍📡

書き方の例👇

  • 「1) は “種類が増える” だからOCPっぽい！でも計算ロジックも整理したいからSRPも必要かも」🧠✨

AI活用コーナー：SOLIDで迷ったときの聞き方🤖💡​

AIは「設計判断」そのものを丸投げすると危ないけど、候補出しには超便利だよ〜😊✨ おすすめ質問テンプレ👇

  • 「このコードの“変わりそうな点”を箇条書きで出して」🔮📝
  • 「変更点ごとに、SRP/OCP/LSP/ISP/DIPの観点で改善案を3つ」🧩✨
  • 「やりすぎ抽象化になりそうな部分も指摘して」⚠️🧠

ちなみに最近のVS Codeの更新（v1.108）では、Copilotの“スキル”を読み込ませる仕組み（Agent Skills）が実験的に入ってて、チェックリストやテンプレを“覚えさせる”方向にも進んでるよ🤖📌 （設定名なども含めて公式の更新内容に載ってる）(Visual Studio Code)

まとめ：この章のゴールは「暗記」じゃなく「地図」🗺️💖​

  • SOLIDは未来の変更コストを下げるための考え方💸✨
  • 「変更点 → 理由 → 境界」って流れで考えると迷いにくい🧭
  • まずは差し替え口を小さく作るところからでOK🙆‍♀️
  • AIは「候補出し＆危険検知」に使うと強い🤖🔍

おまけ：今日の“最新ツール事情”メモ（チラ見せ）👀✨​

  • TypeScriptは 5.9 系が現行（GitHubの最新タグは 5.9.3）(GitHub)
  • Node.js は v24 系が最新LTSとして案内されてるよ(Node.js)
  • VS Codeは v1.108 のリリースノートが公開されてる（2026-01-08の更新）(Visual Studio Code)

次の第9章からは、いよいよ SRP（単一責任）🌷 を“手を動かして”身につけていくよ〜！✂️✨