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

第4章：設計の基本用語（超入門辞書）📖😊✨

この章は「設計の会話ができるようになる」ための用語チートシート回だよ〜🧸💛 SOLIDを学ぶ前に、ここで言葉をそろえると後がめちゃ楽になる👍✨

ちなみに本日時点だと、TypeScriptの安定版は 5.9.3（npmの “latest” 表示）だよ🧡 (npm) そして次の大きい流れとして TypeScript 6.0/7.0（ネイティブ移行） の話も進んでるから、今後さらに「大規模コードを扱う設計力」が効いてくるやつ〜😺🔥 (Microsoft for Developers)

Specialist Chef

この章でできるようになること🎯✨​

  • 「責務」「依存」「抽象」「凝集度」「結合度」などを、自分の言葉で説明できる🗣️😊
  • コードを見たときに「どこがヤバいか」を言語化できる👀💥
  • ミニプロジェクト（Orderまわり）で「変更点」を先読みできる🔮🧠

1) 設計用語の“超入門辞書”📚✨（最重要だけ厳選！）​

Cohesion vs Coupling

✅ 責務（Responsibility）🧩​

一言：そのクラス/関数が「何を担当するか」だよ🙂 合言葉：「この子の仕事って、結局なに？」👩‍🏫 ヤバい兆候：説明するときに「えっと…計算して…保存して…表示して…通知も…」ってなる😇

✅ 変更理由（Reason to change）🔧​

一言：「何が起きたらここを直す羽目になるか」だよ😺 責務とセットで覚えると最強💪✨ 例（Order周辺）：

  • 税率が変わる → 料金計算に影響💰
  • 保存先が変わる（DB→API）→ 永続化に影響🗄️🌐
  • レシートの表示が変わる → 表示/フォーマットに影響🧾

✅ 依存（Dependency）🔗​

一言：あるコードが、別のコードに「頼ってる」状態🙂 見つけ方：newしてる／importしてる／呼び出してる📦 注意：依存が悪いんじゃなくて、依存の向きと強さが問題になることが多いよ🧠✨

✅ 抽象（Abstraction）🎭​

一言：「共通の約束だけ見せて、細部を隠す」こと😊 TypeScriptだと interface が一番わかりやすい✨ 目的：将来の差し替えや変更に強くする🔁🛡️

たとえば「保存する」という抽象だけ見せる👇

interface OrderRepository {
  save(order: Order): Promise<void>;
}

✅ 具体（Implementation / Detail）🧱​

一言：抽象の“中身のやり方”だよ🙂 例：メモリに保存、ファイルに保存、DBに保存…みたいな実装の違い🗃️

✅ カプセル化（Encapsulation）🔐​

一言：「勝手に触られたくない情報やルールを中にしまう」こと😊 private / readonly の出番✨ 狙い：外からいじられない＝バグが減る🧯

✅ 不変条件（Invariant）🧷​

一言：「いつでも守られていてほしいルール」だよ💎 例：quantity >= 1、price >= 0、orderId は空じゃない など。

✅ 凝集度（Cohesion）🧲（高いほど良い✨）​

一言：1つのモジュールの中身が「同じ目的でまとまってる度」😊 高い凝集：みんなで同じ仕事をしてる感じ👯‍♀️ 低い凝集：関係ない機能の寄せ集め🧟‍♂️

✅ 結合度（Coupling）🪢（低いほど良い✨）​

一言：モジュール同士が「どれくらい強く結びついてるか」🙂 低い結合：差し替えやすい🔁 高い結合：ちょっと変えると全部壊れる😵‍💫

✅ 関心の分離（Separation of Concerns）✂️​

一言：「計算」「保存」「表示」「通信」みたいな関心を混ぜないこと😊 SOLIDの土台の空気感がこれ🌬️✨

✅ 境界（Boundary）🚧​

一言：「ここから先は別の世界」って線引き🙂 例：

  • ドメイン（ルール）と インフラ（DB/通信）を分ける → 変更が来やすい場所を隔離できる🧱🛡️

✅ 副作用（Side Effect）💥​

一言：呼んだら「値を返す」以外に、外の世界が変わること😺 例：保存する、ログを出す、通知する、日時を読む、乱数を使う…など。 TypeScript 5.9 では import defer みたいに「モジュール評価（実行タイミング）」を意識する流れも出てきてて、副作用の管理がより大事になるよ〜🧠⚡ (Microsoft for Developers)

✅ 契約（Contract）📜​

一言：interfaceや型が示す「こう使ってね」の約束😊

  • 入力はこれ
  • 出力はこれ
  • この範囲の値を想定してる みたいなやつ✨

2) 例で体に入れる：Orderまわりの“変更点”を想像しよ〜☕️📦🧠​

よくある未来（変更理由）ランキング🏆​

  1. 割引ルールが増える（学割、雨の日割、セット割…）🎟️
  2. 税率・端数処理が変わる（四捨五入→切り上げ等）💰
  3. 保存先が変わる（ローカル→API→DB）🗄️🌐
  4. 通知が増える（メール、アプリ通知、ログ、LINE…）🔔📩
  5. 表示が変わる（レシート形式、UI表示）🧾🎨

この「未来の変更」を先に言葉で持っておくと、SOLIDが刺さる場所が見えてくるよ👀✨

3) ミニ演習①：用語当てゲーム🎮💡（5分）​

次のうち、どの用語っぽい？（直感でOK！）😺

  • 「注文の計算も保存も通知も、全部1クラスでやってる」 → 責務が多い / 凝集が低い っぽい😵‍💫🧩

  • 「DBが変わるだけで、計算ロジックのファイルも直す羽目になった」 → 結合が高い っぽい🪢💥

  • 「保存方法を差し替えたいから interface を作った」 → 抽象 🎭✨

4) ミニ演習②：Order周辺の“用語でレビュー”📝👀（15〜25分）​

ステップ1：自分の言葉で説明してみる🗣️✨​

Orderまわりのクラス（または頭の中の設計）を見て、これを書いてみてね👇

  • このクラスの責務は？（1文で）🧩
  • 変更理由は？（3つ）🔧
  • 依存してる相手は？（列挙）🔗
  • 副作用は？（ある/ない、あるなら何）💥

ステップ2：AIに“言葉を整えてもらう”🤖🧡​

Copilot/Codex系に投げるなら、こんなプロンプトが使いやすいよ👇

  • 「このクラスの責務を1文で言い換えて。変更理由も3つ挙げて」🧸
  • 「依存（import/new/call）を一覧にして、結合が高そうな箇所を指摘して」🔍
  • 「副作用がある関数を列挙して、純粋関数にできる候補を教えて」🧠

※AIの提案は“採用するか”を人間が決めるのが大事だよ〜🙆‍♀️✨（とくに設計はね！）

5) この章のまとめ🎁✨（ここだけ覚えても勝てる）​

  • 責務＝その子の仕事🧩
  • 変更理由＝何が起きたら直す？🔧
  • 依存＝誰に頼ってる？🔗
  • 抽象＝約束だけ見せる🎭
  • 凝集＝中がまとまってる？🧲（高いほど良い）
  • 結合＝外とくっつきすぎ？🪢（低いほど良い）
  • 副作用＝外の世界が変わる？💥

次章へのつながり👃💥​

次の第5章は、この用語を武器にして「コードのニオイ」を嗅ぎ分ける回になるよ〜😊✨ 用語があると、「なんかヤバい」じゃなくて「責務が混ざってて凝集が低い」って言えるようになる👍💛