メインコンテンツまでスキップ
KISS TS版YAGNI TS版SoC TS版ADR TS版HC/LC TS版DRY TS版リファクタリング TS版テスタブル TS版TDD TS版エラーモデリング TS版レイヤー TS版MVC TS版依存関係ルール TS版DIP TS版DI TS版Is-a/Has-a TS版SOLID TS版GoFデザインパターン TS版Observer TS版CQS TS版状態機械 TS版不変条件 TS版Entity/VO TS版DDD TS版集約/境界 TS版ドメインイベント TS版モジュラーモノリス TS版ヘキサゴナル TS版クリーンアーキ TS版ACL TS版API Contract TS版SemVer TS版DbC TS版冪等性 TS版CAP定理 TS版Outbox TS版Saga TS版CQRS TS版イベントソーシング TS版BC TS版

GoFデザインパターン（生成/構造/振る舞い）—TypeScript入門〜中級向け 90章アウトライン（VS Code＋AI前提）

  • 作成日: 2026-02-04
  • 対象: TypeScript 初級〜中級 / GoF初めて / 設計は超入門者
  • 前提: Windows 🪟 / Visual Studio Code 💻 / GitHub Copilot や OpenAI系AI拡張が利用可能 🤖✨
  • 目的: 「パターン暗記」よりも、“どれをいつ使うか”を自分で判断できるようになること🧭

この教材のルール（大事）📌​

  • “パターンのためだけのオレオレ独自クラス”は作りません🙅‍♀️（TypeScript標準・デファクトの書き方を中心にします）
  • まずは 関数・型・標準API で素直に書く → それでも困ったらパターンで整理、の順番にします🌱
  • AIは 下書き係。採用するかはあなたが決める（理由まで言えると最強）💪🤖
  • できるだけ「同じ題材（ミニアプリ）」で進めて、迷子を防ぎます☕🍰

共通題材（例）☕​

  • “カフェ注文ミニアプリ”をずっと育てます：注文・割引・通知・状態遷移・履歴・外部連携（モック）など

Part 0 はじめに・環境・学び方（第1〜第10章）🌸​

第1章 GoFデザインパターンってなに？（地図を持つ学び）🗺️​

  • ねらい🎯：GoFが“暗記科目”じゃないとわかる
  • 学ぶこと📌：パターン＝よくある問題への再利用できる解き方
  • ハンズオン🛠️：自分のコードで「つらい所」を3つメモする
  • AIプロンプト例🤖：『私のコードでつらい点を列挙して、パターンで解決できる可能性がある所を指摘して』
  • つまずき回避💡：最初から全部使おうとしない（1つ効けば勝ち）

第2章 生成・構造・振る舞いの3分類（ざっくり理解）🍡​

  • ねらい🎯：3分類の役割を一言で説明できる
  • 学ぶこと📌：生成＝作り方 / 構造＝組み立て方 / 振る舞い＝動き方
  • ハンズオン🛠️：身近な例（スマホアプリ）を3分類で仕分け
  • AIプロンプト例🤖：『○○アプリの機能を3分類で分けて、どこに設計の悩みが出そうか教えて』
  • つまずき回避💡：分類は“目安”。混ざってOK、目的が先

第3章 この教材の進め方（小さく作って育てる）🌱​

  • ねらい🎯：学習の流れ（作る→困る→パターン）に慣れる
  • 学ぶこと📌：完璧設計より“育てる設計”が現実的
  • ハンズオン🛠️：共通題材（カフェ注文）で最小の動く版を想像する
  • AIプロンプト例🤖：『カフェ注文ミニアプリの最小要件を5つに絞って』
  • つまずき回避💡：最初から汎用化しない（YAGNI的に）

第4章 VS Codeの“設計に効く”機能（リネーム・参照・抽出）🧰​

  • ねらい🎯：設計改善に直結する編集機能を使える
  • 学ぶこと📌：Rename Symbol / Find References / Extract Method など
  • ハンズオン🛠️：名前変更→参照追跡→小関数抽出を1回やる
  • AIプロンプト例🤖：『この関数名、責務が伝わる名前に3案。理由も』
  • つまずき回避💡：編集で壊れたら即戻す（Git活用）

第5章 AI拡張の使いどころ（下書き・比較・説明役）🤖✨​

  • ねらい🎯：AIに“任せる所”と“任せない所”がわかる
  • 学ぶこと📌：任せる＝下書き/テスト案/リファクタ案、任せない＝採用判断
  • ハンズオン🛠️：同じ要求を2通りのプロンプトで投げて結果比較
  • AIプロンプト例🤖：『TypeScriptで○○パターンの最小例を、過剰な独自クラスなしで』
  • つまずき回避💡：AIの“それっぽい正解”を鵜呑みにしない

第6章 プロジェクト雛形（TS＋テスト＋Lintを最小で）🧪​

  • ねらい🎯：学習用の最小プロジェクトを作れる
  • 学ぶこと📌：strictモード / ESM / テストの入口
  • ハンズオン🛠️：1ファイルで関数を書いてテストを1本通す
  • AIプロンプト例🤖：『Windows+VS Code前提で、TypeScript学習用の最小構成（strict）を提案して』
  • つまずき回避💡：構成に沼らない（“動く最小”でOK）

第7章 共通題材を実装（注文・商品・合計だけ）☕🧾​

  • ねらい🎯：共通題材の“素”を作る
  • 学ぶこと📌：まずは単純なデータ構造＋関数でOK
  • ハンズオン🛠️：注文配列→合計計算→出力（consoleでも可）
  • AIプロンプト例🤖：『カフェ注文のデータ構造をTypeScriptの型で提案して（シンプルに）』
  • つまずき回避💡：最初はclassを増やさない（KISS）

第8章 設計の“匂い”を嗅ぐ（つらさのサイン集）👃​

  • ねらい🎯：パターン適用の前に“困りごと”を言語化できる
  • 学ぶこと📌：if分岐の肥大化/引数の増殖/依存の絡まり/重複
  • ハンズオン🛠️：題材コードの“つらい所”にコメントで印をつける
  • AIプロンプト例🤖：『このコードの匂い（保守が辛くなる点）を5つ指摘して。改善案は段階的に』
  • つまずき回避💡：匂い＝悪ではない（規模により許容）

第9章 パターンの判断フロー（まず関数→それでも辛い？）🧭​

  • ねらい🎯：適用判断の手順を持つ
  • 学ぶこと📌：①重複？②差し替え？③増え方？④責務分離？
  • ハンズオン🛠️：匂い→候補パターンを1つ当てる練習
  • AIプロンプト例🤖：『この匂いに効きやすいGoFパターン候補を3つ、理由つきで』
  • つまずき回避💡：最初は“当てゲーム”でOK（精度より習慣）

第10章 まとめ：ここまでの成果物チェック✅🎉​

  • ねらい🎯：最小の題材＋学び方が整う
  • 学ぶこと📌：学習の型（小さく→困る→整理）が手に入る
  • ハンズオン🛠️：今のコードをGitコミット（学習の節目）
  • AIプロンプト例🤖：『現状の構成を要約して、次に改善すると良い点を優先度順に』
  • つまずき回避💡：完成度より“継続できる状態”が大事

Part 1 GoFに入る前の“TypeScript設計の土台”（第11〜第15章）🧱​

第11章 interfaceの使いどころ（型だけで差し替えを作る）🧩​

  • ねらい🎯：interfaceで“差し替え可能”を作れる
  • 学ぶこと📌：構造的型付け／依存を型へ寄せる感覚
  • ハンズオン🛠️：支払い計算をinterface（または関数型）で切り替え
  • AIプロンプト例🤖：『interfaceで依存を剥がす最小例を、カフェ題材で』
  • つまずき回避💡：interface乱立は逆効果。まず小さく1個から

第12章 関数で表現できるパターン（Strategyの前準備）⚙️​

  • ねらい🎯：クラスより関数が自然な場面を掴む
  • 学ぶこと📌：コールバック／高階関数／設定オブジェクト
  • ハンズオン🛠️：割引ロジックを関数で差し替え（if削減）
  • AIプロンプト例🤖：『クラスを使わず、関数だけで差し替えできる設計にして』
  • つまずき回避💡：関数が増えたら“命名”で迷子回避

第13章 判別Unionで“状態/種類”を安全にする（State/Visitorの土台）🚦​

  • ねらい🎯：if/switchの事故を減らせる
  • 学ぶこと📌：discriminated union／網羅チェックの考え方
  • ハンズオン🛠️：注文状態をUnionで表し、許可操作だけ通す
  • AIプロンプト例🤖：『注文状態を判別Unionで設計して、許可されない操作を型で防いで』
  • つまずき回避💡：Unionの“分岐キー”は短く固定（例：type/status）

第14章 Map/Setで“共有・キャッシュ”の基本（Flyweightの土台）🗃️​

  • ねらい🎯：重複生成を防ぐ基本がわかる
  • 学ぶこと📌：Mapキー設計／寿命（いつ消す？）／メモリ意識
  • ハンズオン🛠️：同じ商品情報をMapで共有する（参照は1つ）
  • AIプロンプト例🤖：『Flyweightっぽい共有をMapでやる最小例を』
  • つまずき回避💡：キーがブレると共有できない（正規化大事）

第15章 例外よりResult的な扱い（Command/Chain/Observerの安定化）🧯​

  • ねらい🎯：失敗が連鎖しても壊れにくくする
  • 学ぶこと📌：成功/失敗を戻り値で表現／エラー分類
  • ハンズオン🛠️：注文確定が失敗するケースをResultで表す
  • AIプロンプト例🤖：『例外ではなく戻り値で扱うResult型の最小例を作って』
  • つまずき回避💡：全部Resultにしない。境界（外部I/O）中心でOK

Part 2 生成パターン（Creational）🏭（第16〜第35章）​

第16章 Factory Method ① 困りごと編：new分岐が増えた！😵​

  • ねらい🎯：Factory Methodが効く“症状”を説明できる
  • 学ぶこと📌：生成ロジックの集中／呼び出し側の単純化
  • ハンズオン🛠️：注文の作成が条件で分岐して散らばる例を作る
  • AIプロンプト例🤖：『new分岐が散らばった例と、その痛みを説明して』
  • つまずき回避💡：まずは“生成だけ”を1箇所に寄せる発想でOK

第17章 Factory Method ② TypeScript流：関数Factoryから始めよう🧁​

  • ねらい🎯：クラス工場より先に“関数工場”で解決できる
  • 学ぶこと📌：factory関数／戻り値の型／引数の正規化
  • ハンズオン🛠️：注文タイプ別に生成する createOrder(...) を作る
  • AIプロンプト例🤖：『Factory Methodを関数で表現して（クラス過多にしない）』
  • つまずき回避💡：ファクトリは“作る責務”だけ。計算まで入れない

第18章 Factory Method ③ 拡張に強く：登録（Registry）で増やす📌​

  • ねらい🎯：種類追加でifを増やさない形に近づく
  • 学ぶこと📌：キー→生成関数のMap／未登録時の扱い
  • ハンズオン🛠️：Map<string, () => Order> で生成関数を登録
  • AIプロンプト例🤖：『登録型Factory（Map）にして、型安全も少し意識して』
  • つまずき回避💡：まずstringキーでOK。型安全は次章以降で育てる

第19章 Factory Method ④ まとめ演習：生成と利用側の分離テスト🧪​

  • ねらい🎯：Factoryの恩恵をテストで体感する
  • 学ぶこと📌：生成のテスト／利用側が単純になるメリット
  • ハンズオン🛠️：利用側は createOrder しか知らないように整理
  • AIプロンプト例🤖：『このFactoryに対するテストケース案を10個出して』
  • つまずき回避💡：テストは“代表ケース＋境界ケース”だけで十分

第20章 Abstract Factory ① 困りごと編：部品セットを丸ごと切替えたい🔁​

  • ねらい🎯：Abstract Factoryが必要になる状況を掴む
  • 学ぶこと📌：互いに整合する“家族”の生成（セット販売の発想）
  • ハンズオン🛠️：通知（メール/アプリ）＋文面テンプレをセットで変えたい例
  • AIプロンプト例🤖：『“セットで切り替える”が必要な例をカフェ題材で』
  • つまずき回避💡：単体切替ならFactory Methodで足りることが多い

第21章 Abstract Factory ② TypeScript流：interfaceで“家族”を定義👨‍👩‍👧‍👦​

  • ねらい🎯：生成物の整合性をinterfaceで守れる
  • 学ぶこと📌：Factory interface／関連コンポーネントの型
  • ハンズオン🛠️：NotificationFactory が createSender と createTemplate を返す
  • AIプロンプト例🤖：『Abstract Factoryを最小のinterface構成で。独自クラス増やしすぎないで』
  • つまずき回避💡：クラスを増やす前に“型と関数”で表現できるか考える

第22章 Abstract Factory ③ 実運用っぽく：環境設定で差し替え（DIっぽく）⚙️​

  • ねらい🎯：設定で工場を選ぶ流れが作れる
  • 学ぶこと📌：起動時に選択／依存注入（渡すだけでOK）
  • ハンズオン🛠️：env により Factory を選んでアプリへ渡す
  • AIプロンプト例🤖：『環境変数（設定）でFactoryを差し替える構成を提案して』
  • つまずき回避💡：DIコンテナは不要。渡すだけで成立する

第23章 Abstract Factory ④ まとめ演習：家族の不整合を防ぐテスト✅​

  • ねらい🎯：間違った組み合わせを作れない利点を体感
  • 学ぶこと📌：Factoryが“整合性の門番”になる
  • ハンズオン🛠️：テンプレと送信手段が合わないケースを排除
  • AIプロンプト例🤖：『“間違った組合せ”が起きる例と、テストで防ぐ方法を』
  • つまずき回避💡：テストは“組合せ表”を全部やらなくてOK（代表で）

第24章 Builder ① 困りごと編：引数が多すぎて読めない😵‍💫​

  • ねらい🎯：Builderが効く“引数地獄”を見抜ける
  • 学ぶこと📌：段階的構築／必須と任意の分離
  • ハンズオン🛠️：注文生成の引数が増えまくる例を作る
  • AIプロンプト例🤖：『引数が多いコンストラクタの問題点を説明して、改善案を3つ』
  • つまずき回避💡：まずは“オプションオブジェクト”で十分なことも多い

第25章 Builder ② TypeScriptの定番：オプションオブジェクト＋デフォルト値🧁​

  • ねらい🎯：Builderに行く前の王道解法を使える
  • 学ぶこと📌：{ ... } 引数／partial／default設定
  • ハンズオン🛠️：createOrder({ drink, size, ... }) の形に変える
  • AIプロンプト例🤖：『Builderを使わず、オプションオブジェクトで読みやすくする例を』
  • つまずき回避💡：必須項目は型で必須に（optional乱用しない）

第26章 Builder ③ Builderが必要な瞬間：手順が複雑で“順番”がある🧱​

  • ねらい🎯：Builderの採用判断ができる
  • 学ぶこと📌：手順の強制／中間状態の隠蔽／最終的にbuild
  • ハンズオン🛠️：割引→税→配送→合計…の順序をBuilderで固定
  • AIプロンプト例🤖：『順序依存がある構築処理をBuilderで表現して（過剰クラスは避けて）』
  • つまずき回避💡：Builderは“構築”だけ。業務判断まで抱えない

第27章 Builder ④ まとめ演習：読みやすさチェック（レビュー観点）👀​

  • ねらい🎯：Builder/オプション/関数の使い分けが言える
  • 学ぶこと📌：読みやすさ＝“呼び出し側が気持ちいい”か
  • ハンズオン🛠️：3案（引数/オプション/Builder）で呼び出し比較
  • AIプロンプト例🤖：『3案を比較して、可読性と拡張性の観点でコメントして』
  • つまずき回避💡：一番短いより“一番誤読されない”を選ぶ

第28章 Prototype ① 困りごと編：テンプレから複製したい📄➡️📄​

  • ねらい🎯：Prototypeが効く“コピペ地獄”を避けられる
  • 学ぶこと📌：原型（template）／複製して少し変更
  • ハンズオン🛠️：おすすめセット注文を“ベース”から複製して編集
  • AIプロンプト例🤖：『Prototypeが向く具体例をカフェ題材で。深いコピーも意識して』
  • つまずき回避💡：浅いコピーで事故りやすい（ネスト注意）

第29章 Prototype ② TypeScript標準でやる：スプレッド/structuredClone/assign🧬​

  • ねらい🎯：独自cloneクラスなしで複製できる
  • 学ぶこと📌：浅い/深いコピーの違い／データ設計
  • ハンズオン🛠️：ネストあり注文を“安全に複製”して差分更新
  • AIプロンプト例🤖：『浅いコピーで壊れる例と、直し方（structuredClone等）を示して』
  • つまずき回避💡：関数やDateなどの扱いは要注意（題材は単純に）

第30章 Prototype ③ “不変”と相性が良い：変更はコピーで表現🧊​

  • ねらい🎯：Memento/Undoにもつながる発想を持つ
  • 学ぶこと📌：immutable更新／差分適用の習慣
  • ハンズオン🛠️：updateOrder(base, patch) のように差分更新関数を作る
  • AIプロンプト例🤖：『不変更新（immutable）でprototype的に更新する例を』
  • つまずき回避💡：何でも不変にしない。状態管理が欲しい所だけ

第31章 Prototype ④ まとめ演習：複製＋編集のUI想定シナリオ🧁​

  • ねらい🎯：実務の“テンプレ機能”に落とし込める
  • 学ぶこと📌：テンプレ一覧／複製後の編集／履歴
  • ハンズオン🛠️：テンプレ→新規注文→編集→保存の流れを作る
  • AIプロンプト例🤖：『テンプレ機能のユースケースを整理して、データ設計案を』
  • つまずき回避💡：テンプレは“読み取り専用”にして事故を防ぐ

第32章 Singleton ① 危険も学ぶ：便利だけど依存が隠れる⚠️​

  • ねらい🎯：Singletonの“落とし穴”を説明できる
  • 学ぶこと📌：グローバル状態／テスト困難／密結合
  • ハンズオン🛠️：雑にSingletonでログを作ってテストが辛いのを体験
  • AIプロンプト例🤖：『Singletonのメリット/デメリットをTypeScript視点で簡潔に』
  • つまずき回避💡：まず“使わない選択肢”を知るのが大事

第33章 Singleton ② TypeScriptの定番：モジュールのexportで十分📦​

  • ねらい🎯：独自Singletonクラスを作らずに済む
  • 学ぶこと📌：ESMモジュールは基本1回だけ評価される性質
  • ハンズオン🛠️：export const logger = ... で共有インスタンスを提供
  • AIプロンプト例🤖：『Singletonクラス無しで共有インスタンスを実現する例を』
  • つまずき回避💡：共有が必要か？を毎回疑う（依存が隠れる）

第34章 Singleton ③ 代替案：DI（引数で渡す）にするとテスト楽💉​

  • ねらい🎯：Singletonを避ける設計ができる
  • 学ぶこと📌：依存を引数へ／デフォルト実装を用意
  • ハンズオン🛠️：loggerを引数で渡してテスト差し替え
  • AIプロンプト例🤖：『logger依存を引数注入に変えて、テストしやすくする手順を』
  • つまずき回避💡：全部注入は疲れる。重要依存だけでOK

第35章 Singleton ④ まとめ演習：設定・ログ・キャッシュの扱い方📌​

  • ねらい🎯：Singletonが許されるケースを言語化できる
  • 学ぶこと📌：読み取り中心/副作用少/テスト容易の工夫
  • ハンズオン🛠️：設定（read-only）だけは共有、ログは注入…など方針を決める
  • AIプロンプト例🤖：『“共有しても安全”なものと危険なものを分類して』
  • つまずき回避💡：方針はREADMEに書く（チームでぶれない）

Part 3 構造パターン（Structural）🏗️（第36〜第56章）​

第36章 Adapter ① 外部APIの形が合わない問題🔌​

  • ねらい🎯：Adapterの出番を即答できる
  • 学ぶこと📌：外部DTOと内部モデルの分離／変換責務
  • ハンズオン🛠️：外部の注文レスポンス（字段名が違う）を内部型へ変換
  • AIプロンプト例🤖：『外部DTO→内部型への変換（Adapter）をTypeScriptで。余計なクラス無しで』
  • つまずき回避💡：変換は1箇所に集める（散らばると地獄）

第37章 Adapter ② TypeScriptの王道：マッピング関数＋型ガード🧩​

  • ねらい🎯：安全な変換（欠損/型違い）を作れる
  • 学ぶこと📌：type guard／正規化（null/undefinedの扱い）
  • ハンズオン🛠️：toDomainOrder(dto) で欠損を吸収して安全化
  • AIプロンプト例🤖：『型ガード込みのDTO変換関数を作って。落とし穴も教えて』
  • つまずき回避💡：adapterで“正しく失敗”させる（曖昧に通さない）

第38章 Adapter ③ まとめ：境界を守ると設計が汚れない🧼​

  • ねらい🎯：Adapterを“境界の掃除係”として使える
  • 学ぶこと📌：ドメインに外部の命名/単位を持ち込まない
  • ハンズオン🛠️：外部の金額（文字列）→内部の数値へ正規化
  • AIプロンプト例🤖：『命名/単位/欠損を吸収するAdapterのチェックリストを』
  • つまずき回避💡：変換しながら業務判断まで混ぜない（責務分離）

第39章 Bridge ① 2軸が増えて爆発する問題（機能×実装）💥​

  • ねらい🎯：Bridgeが必要な“組合せ爆発”を見抜ける
  • 学ぶこと📌：抽象（やりたいこと）と実装（どうやるか）を分離
  • ハンズオン🛠️：出力（画面/ログ）×通知（即時/遅延）が増える例
  • AIプロンプト例🤖：『組合せ爆発の例を示して、Bridgeで分ける設計案を』
  • つまずき回避💡：単純ならStrategyで足りることもある

第40章 Bridge ② TypeScript定番：interface実装を注入（DIっぽく）💉​

  • ねらい🎯：Bridgeをinterface注入で書ける
  • 学ぶこと📌：抽象クラス/コンポジション／実装差し替え
  • ハンズオン🛠️：Notifier が Sender（実装側）を受け取る形にする
  • AIプロンプト例🤖：『BridgeをTypeScriptで最小構成に。クラス増やしすぎないで』
  • つまずき回避💡：抽象は薄く、実装差分が大きい所にだけ使う

第41章 Bridge ③ まとめ：差し替えテストで“価値”を確認🧪​

  • ねらい🎯：差し替えでテストが簡単になるのを体感
  • 学ぶこと📌：本番実装とテスト用実装（スタブ）の考え方
  • ハンズオン🛠️：Senderをモック差し替えして通知処理を単体テスト
  • AIプロンプト例🤖：『Senderのテストダブル（stub/mock）案を出して』
  • つまずき回避💡：テストが書けない設計は“依存が隠れてる”サイン

第42章 Composite ① 木構造を同じ操作で扱いたい🌳​

  • ねらい🎯：Compositeの狙い（葉と枝を同一視）がわかる
  • 学ぶこと📌：Leaf/Composite共通interface／再帰処理
  • ハンズオン🛠️：メニュー（カテゴリ→商品）を同じ price() で計算
  • AIプロンプト例🤖：『Compositeの最小例をカフェ題材で。再帰も含めて』
  • つまずき回避💡：深い木はデバッグが大変。ログで可視化する

第43章 Composite ② TypeScript流：Unionでも表現できる（クラスを増やさない）🧩​

  • ねらい🎯：Compositeを“型”でシンプルに書ける
  • 学ぶこと📌：判別Union＋再帰型／関数で操作
  • ハンズオン🛠️：type Node = {type:'leaf'...} | {type:'group'...} で実装
  • AIプロンプト例🤖：『Compositeをクラス無し（Union+関数）で書く案を』
  • つまずき回避💡：Unionが増えるとswitchも増える。用途で選ぶ

第44章 Composite ③ まとめ：探索（検索/集計）のパターン化🔍​

  • ねらい🎯：木構造の検索・集計を安全に書ける
  • 学ぶこと📌：DFS/BFSのイメージ／Iterator章への布石
  • ハンズオン🛠️：木から「割引対象の商品だけ集計」などを実装
  • AIプロンプト例🤖：『木構造から条件に合う要素を集める関数を、テスト付きで』
  • つまずき回避💡：再帰が怖い時はスタック（配列）でループでもOK

第45章 Decorator ① 機能を“あと付け”で重ねたい🎁​

  • ねらい🎯：Decoratorの狙い（ラップして追加）がわかる
  • 学ぶこと📌：継承ではなく合成で機能追加／順序も意味を持つ
  • ハンズオン🛠️：料金計算に「ログ」「計測」「キャッシュ」を後付け
  • AIプロンプト例🤖：『Decoratorを関数ラップで実装して（TSの自然な書き方で）』
  • つまずき回避💡：ラップが深くなると追いにくい→命名とログ

第46章 Decorator ② TypeScriptの定番：高階関数でサクッとラップ⚙️​

  • ねらい🎯：クラスDecoratorじゃなくGoF Decoratorを体得
  • 学ぶこと📌：(fn)=>((...args)=>{...fn(...)}) の形
  • ハンズオン🛠️：withLogging, withTiming, withRetry を作る
  • AIプロンプト例🤖：『withTiming/withLoggingを型安全に書いて。ジェネリクスも使ってOK』
  • つまずき回避💡：例外/Resultの扱いを統一しないとカオスになる

第47章 Decorator ③ まとめ：責務の分解と再利用の気持ちよさ✨​

  • ねらい🎯：横断関心（ログ等）を分離できる
  • 学ぶこと📌：本体ロジックを汚さずに強化する発想
  • ハンズオン🛠️：Decoratorの組合せ順で結果が変わる例を確認
  • AIプロンプト例🤖：『Decoratorの順序が重要になる例を2つ作って説明して』
  • つまずき回避💡：何でもDecoratorにしない。必要な所だけ

第48章 Facade ① 複雑すぎる機能に“入口”を作る🚪​

  • ねらい🎯：Facadeの狙い（使う側を簡単に）を理解する
  • 学ぶこと📌：複数手順のまとめ役／外から見えるAPIを絞る
  • ハンズオン🛠️：注文確定（検証→割引→在庫→通知）を1関数にまとめる
  • AIプロンプト例🤖：『複数手順をまとめるFacadeのAPI設計案を。責務も説明して』
  • つまずき回避💡：Facadeが巨大化したら“中身”を整理

第49章 Facade ② TypeScriptの定番：サービス関数/クラス1枚でOK🧁​

  • ねらい🎯：Facadeを過剰構造にしない
  • 学ぶこと📌：public APIは少なく／内部は小関数へ分解
  • ハンズオン🛠️：placeOrder(...) の中身を小関数に分ける
  • AIプロンプト例🤖：『この長い関数をFacadeとして整理して、小関数に分割して』
  • つまずき回避💡：分割は“意味のある単位”で

第50章 Facade ③ まとめ：呼び出し側のコードが短くなる🎉​

  • ねらい🎯：利用側が読みやすくなる価値を確認
  • 学ぶこと📌：UI/CLI/APIが同じFacadeを使える
  • ハンズオン🛠️：呼び出し側（UI想定）を短く書き直す
  • AIプロンプト例🤖：『利用側コードを最小化するFacadeの設計を、例つきで』
  • つまずき回避💡：Facadeは“隠す”だけでなく“守る”（誤用防止）

第51章 Flyweight ① 同じものを作りすぎて重い！🐢​

  • ねらい🎯：Flyweightの出番（大量オブジェクト）を掴む
  • 学ぶこと📌：共有できる部分と個別部分の分離
  • ハンズオン🛠️：大量の商品表示で同じアイコン/スタイルを共有したい例
  • AIプロンプト例🤖：『Flyweightの共有/個別をカフェ題材で例示して』
  • つまずき回避💡：最適化は早すぎ注意。必要になってから

第52章 Flyweight ② TypeScript標準：Mapキャッシュで共有する🗃️​

  • ねらい🎯：独自Flyweightクラスなしで実装できる
  • 学ぶこと📌：Map でキー→共有オブジェクト
  • ハンズオン🛠️：getIcon(name) がMapから返す（なければ作る）
  • AIプロンプト例🤖：『MapキャッシュでFlyweightを実装。キー設計の注意も入れて』
  • つまずき回避💡：キャッシュの寿命（破棄）を考える（簡易でOK）

第53章 Flyweight ③ まとめ：計測して“本当に効いたか”確認⏱️​

  • ねらい🎯：最適化は計測とセットだと理解する
  • 学ぶこと📌：観測（ログ/メトリクス）的な入口
  • ハンズオン🛠️：生成回数をカウントして、共有で減るのを確認
  • AIプロンプト例🤖：『Flyweightの効果を可視化する簡単な計測案を』
  • つまずき回避💡：速さより“正しさ”が先

第54章 Proxy ① 代理人を置きたい（遅延/制限/監視/キャッシュ）🕵️​

  • ねらい🎯：Proxyの使いどころを4つ言える
  • 学ぶこと📌：Virtual/Protection/Logging/Caching など
  • ハンズオン🛠️：API呼び出しをProxyでキャッシュ＆レート制限
  • AIプロンプト例🤖：『Proxyの代表用途をTypeScript標準のProxyで例示して』
  • つまずき回避💡：本体とProxyの責務境界を曖昧にしない

第55章 Proxy ② TypeScript標準：JavaScriptの Proxy を使う✨​

  • ねらい🎯：独自プロキシクラスを作らずに済む
  • 学ぶこと📌：トラップ（get/set/apply）／型付けのコツ
  • ハンズオン🛠️：オブジェクトアクセスを監視ログするProxyを作る
  • AIプロンプト例🤖：『JS Proxyでログを入れる例。TypeScript型もなるべく綺麗に』
  • つまずき回避💡：Proxyはデバッグが難しい→ログを丁寧に

第56章 Proxy ③ まとめ：やりすぎ注意（魔法に見えて危険）🧯​

  • ねらい🎯：Proxyの副作用（分かりにくさ）を理解する
  • 学ぶこと📌：隠れた挙動／パフォーマンス／テスト
  • ハンズオン🛠️：Proxyあり/なしで可読性を比較してメモ
  • AIプロンプト例🤖：『Proxyを使うべきでない場面を具体例で3つ』
  • つまずき回避💡：最初は“限定的に”使う（範囲を狭く）

Part 4 振る舞いパターン（Behavioral）🎭（第57〜第89章）​

第57章 Strategy ① まずは関数で差し替える（最重要その1）⚙️​

  • ねらい🎯：Strategyの核＝“やり方を差し替える”を掴む
  • 学ぶこと📌：ifの削減／ポリシーの切替
  • ハンズオン🛠️：割引計算を関数で差し替え
  • AIプロンプト例🤖：『Strategyをクラスではなく関数で。拡張しやすい形に』
  • つまずき回避💡：戦略が増えたら“名前”と“登録場所”を決める

第58章 Strategy ② デファクト：配列/Mapで戦略を登録する🗂️​

  • ねらい🎯：戦略追加でコードが散らばらない形にする
  • 学ぶこと📌：Map登録／デフォルト戦略
  • ハンズオン🛠️：会員ランク別に戦略を登録して選択
  • AIプロンプト例🤖：『Strategy登録（Map）と選択ロジックを、型安全も意識して』
  • つまずき回避💡：キーの設計が命。増え方を想像して決める

第59章 Strategy ③ まとめ：テストが超簡単になる🧪🎉​

  • ねらい🎯：戦略ごとに独立してテストできる
  • 学ぶこと📌：戦略＝純粋関数に寄せると強い
  • ハンズオン🛠️：戦略を3個作ってテストも3本
  • AIプロンプト例🤖：『割引戦略のテストケースを境界値も含めて提案して』
  • つまずき回避💡：戦略がI/Oし始めたら分離

第60章 Observer ① “通知したい”を疎結合でやる（最重要その2）📣​

  • ねらい🎯：Observer＝購読して通知を受け取る仕組みを理解
  • 学ぶこと📌：発行側は受信側を知らない
  • ハンズオン🛠️：注文確定→在庫更新→ログ→UI更新 を通知で繋ぐ
  • AIプロンプト例🤖：『Observerの最小例を、標準API中心で（独自イベントバス作りすぎない）』
  • つまずき回避💡：イベント名が乱立しがち→命名規約

第61章 Observer ② TypeScriptの定番：EventTarget / EventEmitterの使い分け🧠​

  • ねらい🎯：標準/デファクトを中心にObserverを書ける
  • 学ぶこと📌：学習はまずEventTargetで1本化
  • ハンズオン🛠️：EventTargetでイベント通知を実装
  • AIプロンプト例🤖：『EventTargetを使った購読/通知の例。型安全なイベント名の工夫も』
  • つまずき回避💡：最初は環境を混ぜない

第62章 Observer ③ まとめ：イベント設計（粒度・名前・ペイロード）📦​

  • ねらい🎯：イベントを“仕様”として設計できる
  • 学ぶこと📌：過去形／必要十分なデータ
  • ハンズオン🛠️：イベント一覧を作り、payload型を定義
  • AIプロンプト例🤖：『イベント名とpayload設計をレビューして。過不足も指摘して』
  • つまずき回避💡：イベントが多すぎるならまとめる

第63章 Command ① 操作を“命令”として扱う（Undo/履歴に強い）🎮​

  • ねらい🎯：Commandのメリット（履歴・キュー・取り消し）を理解
  • 学ぶこと📌：execute/undo
  • ハンズオン🛠️：トッピング追加・削除をCommand化
  • AIプロンプト例🤖：『CommandでUndoできる最小構成を、カフェ題材で』
  • つまずき回避💡：最初はundo無しでもOK

第64章 Command ② TypeScript定番：関数Command＋履歴配列📚​

  • ねらい🎯：クラスを増やさずCommandを表現できる
  • 学ぶこと📌：do/undo関数
  • ハンズオン🛠️：履歴にpushしてundoで戻す
  • AIプロンプト例🤖：『関数Commandで、履歴とundoを作って。テストも少し』
  • つまずき回避💡：副作用の範囲を小さく

第65章 Command ③ まとめ：キュー/リトライ/トランザクションっぽさ🧾​

  • ねらい🎯：Commandが“後で実行”にも効くと知る
  • 学ぶこと📌：再実行／順序
  • ハンズオン🛠️：失敗するCommandを混ぜて結果をまとめる
  • AIプロンプト例🤖：『Command実行結果を集約する設計（成功/失敗）を提案して』
  • つまずき回避💡：本格キューは後で

第66章 State ① if地獄を卒業：状態で振る舞いが変わる🚦​

  • ねらい🎯：Stateが効く“状態分岐の増殖”を止める
  • 学ぶこと📌：許可操作／遷移
  • ハンズオン🛠️：注文状態でできる操作を分ける
  • AIプロンプト例🤖：『注文の状態遷移を表にして、禁止操作も含めて設計して』
  • つまずき回避💡：状態は少なく始める

第67章 State ② TypeScriptの定番：判別Unionで型安全に（まずこれ）🧠​

  • ねらい🎯：Unionで安全に書ける
  • 学ぶこと📌：網羅チェック／遷移関数
  • ハンズオン🛠️：遷移イベントをUnionで表現
  • AIプロンプト例🤖：『Stateを判別Union＋遷移関数で。網羅チェックも入れて』
  • つまずき回避💡：switchが長くなったら分割

第68章 State ③ まとめ：状態機械の考え方（軽く）📋​

  • ねらい🎯：状態遷移表を作って話せる
  • 学ぶこと📌：ガード条件
  • ハンズオン🛠️：表（Markdown）とコードを一致させる
  • AIプロンプト例🤖：『この状態遷移表から遷移関数を生成して。禁止遷移はエラーに』
  • つまずき回避💡：表とコードのズレはテストで守る

第69章 Chain of Responsibility ① “順番に流す”処理が欲しい⛓️​

  • ねらい🎯：Chainが効く“前処理だらけ”問題を解く
  • 学ぶこと📌：責務を小さく分け順に適用
  • ハンズオン🛠️：検証→割引→在庫→通知 をチェーン化
  • AIプロンプト例🤖：『ミドルウェア風チェーンをTypeScriptで。関数配列でシンプルに』
  • つまずき回避💡：各ステップは小さく

第70章 Chain ② TypeScript定番：関数配列＝ミドルウェア🧁​

  • ねらい🎯：クラスを増やさずChainを実装できる
  • 学ぶこと📌：pipeline
  • ハンズオン🛠️：runPipeline(steps, ctx) を作る
  • AIプロンプト例🤖：『reduceで実装するpipelineと、読みやすい書き方を提案して』
  • つまずき回避💡：途中で止める条件を統一

第71章 Chain ③ まとめ：責務の境界が見えると強い👀✨​

  • ねらい🎯：追加/削除が怖くなくなる
  • 学ぶこと📌：順番依存の注意
  • ハンズオン🛠️：途中で止めるステップ（権限NG等）を追加
  • AIプロンプト例🤖：『チェーンの可視化ログを入れて、デバッグしやすくして』
  • つまずき回避💡：順番が重要なら理由を残す

第72章 Iterator ① “順番に取り出す”を統一する🔁​

  • ねらい🎯：Iteratorで走査コードの重複を減らす
  • 学ぶこと📌：Iterable/Iterator
  • ハンズオン🛠️：木構造を“順に”取り出したい欲求を作る
  • AIプロンプト例🤖：『Iteratorがないとつらい走査コード例と、改善案を』
  • つまずき回避💡：まずfor..ofでOK

第73章 Iterator ② TypeScript標準：Symbol.iterator とジェネレータ✨​

  • ねらい🎯：標準のIterableを自作できる
  • 学ぶこと📌：ジェネレータとyield
  • ハンズオン🛠️：木構造を深さ優先でyieldする
  • AIプロンプト例🤖：『ジェネレータでDFSイテレータを実装して。TypeScriptで型も丁寧に』
  • つまずき回避💡：再帰が怖ければスタックで

第74章 Iterator ③ まとめ：APIが“for..ofできる”だけで嬉しい🎁​

  • ねらい🎯：利用側がシンプルになる価値を体感
  • 学ぶこと📌：順番の差し替え
  • ハンズオン🛠️：同じデータでDFS/BFSを切り替える
  • AIプロンプト例🤖：『DFSとBFSのIteratorを差し替え可能にする案を』
  • つまずき回避💡：順序もテストする

第75章 Mediator ① 部品同士が直接しゃべりすぎ問題🕊️​

  • ねらい🎯：Mediatorで密結合をほどく
  • 学ぶこと📌：仲介者に集約
  • ハンズオン🛠️：UI部品が相互参照して辛い例を作る
  • AIプロンプト例🤖：『部品同士の密結合をMediatorで解く例を。イベント中心で』
  • つまずき回避💡：Mediatorが巨大化→責務分割

第76章 Mediator ② TypeScript定番：イベント中心（Observerと親戚）📣​

  • ねらい🎯：Observerとの違いを言える
  • 学ぶこと📌：Mediatorは調停ルールも持つ
  • ハンズオン🛠️：Aが変わったらB更新ルールをMediatorへ
  • AIプロンプト例🤖：『ObserverとMediatorの違いを、同じ題材で比較して』
  • つまずき回避💡：ルール増ならState/Strategy併用検討

第77章 Mediator ③ まとめ：画面ロジックが整理される✨​

  • ねらい🎯：UI変更が局所化
  • 学ぶこと📌：ログで追える
  • ハンズオン🛠️：更新フローを図にする
  • AIプロンプト例🤖：『Mediatorの責務が増えすぎた時の分割案を』
  • つまずき回避💡：神クラス化させない

第78章 Memento ① 状態をスナップショットで戻したい📸​

  • ねらい🎯：Undo/Redoの発想を掴む
  • 学ぶこと📌：状態保存と復元
  • ハンズオン🛠️：注文編集の戻る/進む
  • AIプロンプト例🤖：『MementoでUndo/Redoを作る最小例を。状態は不変で』
  • つまずき回避💡：学習ではまず丸ごと保存でOK

第79章 Memento ② TypeScript定番：immutable状態＋履歴配列🗂️​

  • ねらい🎯：オレオレMementoクラスなしで実装できる
  • 学ぶこと📌：history/index管理
  • ハンズオン🛠️：push/undo/redo
  • AIプロンプト例🤖：『履歴管理（index付き）を実装して。境界ケースも考慮して』
  • つまずき回避💡：新規編集でredoは捨てる

第80章 Memento ③ まとめ：Commandと組むと超強い💪​

  • ねらい🎯：Command×Mementoの相性を理解
  • 学ぶこと📌：差分/状態の選択肢
  • ハンズオン🛠️：2方式を比較メモ
  • AIプロンプト例🤖：『Undo実装をCommand方式/Memento方式で比較して、判断基準を』
  • つまずき回避💡：小規模はMementoで十分

第81章 Template Method ① 手順は同じ、でも一部だけ違う🧁​

  • ねらい🎯：共通フロー＋差分の整理を理解
  • 学ぶこと📌：骨組み＋差分
  • ハンズオン🛠️：レシート出力の共通手順＋差分
  • AIプロンプト例🤖：『Template Methodが向く例を題材で。差分点も明確に』
  • つまずき回避💡：差分が多いならStrategyも検討

第82章 Template Method ② TypeScript定番：抽象クラスは最小限に🧩​

  • ねらい🎯：抽象クラスを必要な時だけ使える
  • 学ぶこと📌：abstract/hook
  • ハンズオン🛠️：共通手順＋差分メソッド
  • AIプロンプト例🤖：『抽象クラスの設計をレビューして。責務が重いなら改善案も』
  • つまずき回避💡：継承増えすぎたらDecorator/Strategyへ

第83章 Template Method ③ まとめ：手順の統一でバグが減る✅​

  • ねらい🎯：抜け漏れ防止
  • 学ぶこと📌：共通手順テスト
  • ハンズオン🛠️：共通/差分のテスト分離
  • AIプロンプト例🤖：『Template Methodのテスト戦略（共通/差分）を提案して』
  • つまずき回避💡：抽象化しすぎ注意

第84章 Interpreter ① “小さな言語”を解釈したい（発展）🧠​

  • ねらい🎯：構文木で評価する発想を知る
  • 学ぶこと📌：トークン→構文→評価
  • ハンズオン🛠️：簡単な条件式を扱いたい状況を作る
  • AIプロンプト例🤖：『超小さい言語（条件式）を設計して、構文木と評価を説明して』
  • つまずき回避💡：実務は既存DSLが多い。概念理解でOK

第85章 Interpreter ② TSで現実的に：まずは“関数合成”で代替も検討⚙️​

  • ねらい🎯：必要性を判断できる
  • 学ぶこと📌：外部入力ならInterpreter寄り
  • ハンズオン🛠️：関数案と文字列式案を比較
  • AIプロンプト例🤖：『Interpreterと関数合成の代替案を比較して。判断基準も』
  • つまずき回避💡：学習は最小で止める

第86章 Interpreter ③ まとめ：安全性とテストが命🧪​

  • ねらい🎯：解釈系はテスト最重要と理解
  • 学ぶこと📌：無効入力とエラー表現
  • ハンズオン🛠️：無効式で正しく失敗させる
  • AIプロンプト例🤖：『Interpreterのテストケースを現実的な量で提案して』
  • つまずき回避💡：危険入力なら既存ライブラリも検討

第87章 Visitor ① 構造は固定、処理をどんどん追加したい（発展）🧳​

  • ねらい🎯：処理追加が楽になる狙いを理解
  • 学ぶこと📌：構造と処理の分離
  • ハンズオン🛠️：同じ木に表示/集計/検証を追加したくなる状況を作る
  • AIプロンプト例🤖：『Visitorが向く/向かない状況を例で説明して』
  • つまずき回避💡：構造側が増える世界では相性が悪い

第88章 Visitor ② TSの現実解：判別Union＋関数で“訪問”する🧠​

  • ねらい🎯：GoF VisitorをTSらしく軽量に扱う
  • 学ぶこと📌：visit関数＋網羅チェック
  • ハンズオン🛠️：visitorを関数群オブジェクトとして定義
  • AIプロンプト例🤖：『判別UnionでVisitorを実装して。網羅性と読みやすさを両立して』
  • つまずき回避💡：ファイル増に備えて整理ルール

第89章 Visitor ③ まとめ：Composite/Iteratorと合わせ技で強い💪✨​

  • ねらい🎯：複合構造の道具箱として理解
  • 学ぶこと📌：探索＝Iterator、処理追加＝Visitor、構造＝Composite
  • ハンズオン🛠️：集計Visitor/表示Visitorを追加
  • AIプロンプト例🤖：『Composite+Iterator+Visitorの役割分担を文章でまとめて』
  • つまずき回避💡：必要な分だけ採用する

Part 5 仕上げ（第90章）🎓​

第90章 総合演習：カフェ注文ミニアプリを“パターンで育てる”🎉​

  • ねらい🎯：GoFを“暗記”ではなく“判断”で使えるようになる
  • 学ぶこと📌：選定理由／副作用（複雑化）とのバランス
  • ハンズオン🛠️：①割引Strategy ②通知Observer ③状態State ④前処理Chain ⑤履歴Command/Memento ⑥外部連携Adapter ⑦入口Facade
  • AIプロンプト例🤖：『現状コードを読み、次に入れるべきパターンを優先度順に提案して。理由・代替案・リスクも』
  • つまずき回避💡：読みやすさが最優先🧡

付録：超ざっくり選び方チートシート📝✨​

  • 差し替えたい → Strategy / Bridge
  • 通知したい → Observer（調停ルールも欲しい → Mediator）
  • 状態で挙動が変わる → State（まずUnion）
  • 前処理が増える → Chain
  • 操作を履歴にしたい → Command / Memento
  • 外部の形が合わない → Adapter
  • 複雑な手順に入口を作る → Facade
  • 大量の同じ物が重い → Flyweight（Map共有）
  • 代理を置く（キャッシュ/監視） → Proxy（JS標準Proxy）
  • 木構造を統一操作 → Composite（＋Iterator/Visitorは発展）

付録：AIに投げる“型”プロンプト（コピペ用）🤖💬​

あなたはTypeScriptの先生です。次の制約で、設計案と最小実装を提案してください。
- Windows + VS Code 前提
- GoFパターン目的のオレオレ独自クラスは作らない（標準/デファクト中心）
- まず関数・型でシンプルに。必要ならGoFパターンを採用
- 出力: 1) ねらい 2) 設計（責務/依存）3) 最小コード 4) テスト案 5) 注意点
題材: カフェ注文ミニアプリ
相談内容: <ここに悩みを書く>