practicing-getting-start-design-pattern

name	practicing-getting-start-design-pattern
description	デザインパターンからはじめるプログラミング入門」の対話式チュートリアル。GoF デザインパターンを TDD で 14 言語に実装しながら学ぶ。「デザインパターンを学びたい」「Strategy パターンを実装したい」「Template Method を練習したい」「Java でデザインパターンを体験したい」「Ruby でパターンを学びたい」「getting-start-design-pattern をやりたい」「GoF パターンのハンズオンがしたい」「Observer パターンを実装してみたい」「デザインパターン入門チュートリアルをやりたい」「パターンを TDD で実装したい」「Composite パターンを理解したい」「Factory パターンを書きたい」といった場面で発動する。デザインパターンの学習やパターン実装の要望があれば積極的に使用すること。

デザインパターン プログラミング入門 - 対話式チュートリアル

GoF デザインパターンを題材に、TDD（テスト駆動開発）の手法でパターンを実装しながら学ぶ対話式チュートリアル。Russ Olsen『Design Patterns in Ruby』をベースに、各言語のイディオムに沿ったパターン実装を体験する。前作「テスト駆動開発から始めるプログラミング入門」の続編として位置づけられる。

教材

docs/article/ に 14 言語 x 16 章の完全な教材がある。チュートリアル進行時は該当する言語・章の教材を参照し、内容に沿って進行する。

教材構成

docs/article/
├── outline.md                        # 執筆計画アウトライン
├── workflow.md                       # 執筆ワークフロー
├── ruby/                             # Ruby（源流）
├── java/                             # Java
├── python/                           # Python
├── javascript/                       # JavaScript
├── typescript/                       # TypeScript
├── csharp/                           # C#
├── fsharp/                           # F#
├── php/                              # PHP
├── go/                               # Go
├── rust/                             # Rust
├── clojure/                          # Clojure
├── scala/                            # Scala
├── elixir/                           # Elixir
├── haskell/                          # Haskell
└── all/                              # 多言語統合解説

一次資料

Ruby の参照実装が docs/reference/ruby-design-pattern/ にある。各パターンの .rb ファイル、テスト、PlantUML クラス図が含まれる。

チュートリアルの進め方

Step 0: 開発環境の準備

チュートリアルを始める前に、開発環境を準備する。環境構築はユーザーにインストラクションを提示し、合意を得てから進める。勝手にコマンドを実行しない。

コード配置ルール

チュートリアルで作成するコードは apps/ 配下に言語ごとのディレクトリを切り、さらに design-pattern/ サブディレクトリ内にパターンごとのプロジェクトを配置する。

apps/
├── ruby/
│   └── design-pattern/
│       ├── 04-template-method/
│       ├── 05-strategy/
│       └── ...
├── java/
│   └── design-pattern/
│       └── ...
├── python/
│   └── design-pattern/
│       └── ...
└── ...           # その他の言語も同様

進め方：

1. 選択言語のディレクトリ apps/{lang}/design-pattern/ が存在するか確認する
2. なければ作成し、各言語標準のプロジェクト初期化コマンドをユーザーの合意を得てから実行する
3. 以降のテスト・実装コードはすべてこのディレクトリ配下に記述する

推奨環境: GitHub Codespaces

最もスムーズに始められる環境。devcontainer に Nix が設定済みで、言語ごとの開発環境が即座に利用可能。

# Codespace 起動後、選択した言語の開発環境に入る
nix develop .#ruby    # Ruby の場合
nix develop .#java    # Java の場合
nix develop .#python  # Python の場合
nix develop .#node    # JavaScript/TypeScript の場合
# ... 各言語に対応した flake が用意されている

ローカル環境

ローカルで進める場合は、OS に応じたパッケージマネージャで各言語の開発環境を構築する。

OS	パッケージマネージャ	環境構築方法
Windows（WSL 推奨）	WSL + Nix	WSL2（Ubuntu 等）に Nix をインストールし nix develop .#{lang} で開発環境に入る
Windows（ネイティブ）	Scoop	Scoop で各言語のランタイム・ビルドツールを直接インストール（Nix は非対応）
macOS	Homebrew + Nix	Nix で nix develop .#{lang} または Homebrew で個別インストール
Linux	Nix	nix develop .#{lang} で開発環境に入る

環境構築の進め方

1. ユーザーの現在の環境（OS、既存ツール）を確認する
2. 推奨環境（GitHub Codespaces）を提案する
3. ローカル環境を希望する場合は、OS に応じたインストール手順を提示して確認を求める
4. ユーザーの合意を得てから、ステップごとにコマンドを実行する
5. 環境が正しく構築できたことを確認してからチュートリアルに進む

Step 1: 言語選択

ユーザーに学びたい言語を尋ねる。対応言語と、デザインパターン学習における特徴を簡潔に提示する。

言語	パターン理解の重点
Ruby	源流。ブロック、Module、メタプログラミング
Java	GoF 本のメインターゲット。インターフェースと継承
JavaScript	プロトタイプ、関数オブジェクト、動的ディスパッチ
TypeScript	静的型付け、ジェネリクス、ユニオン型
Python	ダックタイピング、デコレータ言語機能
PHP	漸進的型付け、トレイト
Go	構造的型、継承なしでの委譲・組み込み
Rust	トレイト、所有権、列挙型による多態
C#	LINQ、デリゲート、拡張メソッド
F#	関数型ファースト、判別共用体、Computation Expression
Clojure	プロトコル、マルチメソッド、不変データ
Scala	型クラス、暗黙、パターンマッチ
Elixir	プロセス、Behaviour、関数のパイプライン
Haskell	型クラス、モナド、純粋関数

Step 2: 章の選択

全 16 章 4 部構成。ユーザーの経験レベルとパターンへの関心に応じて開始章を提案する。

第 1 部: パターンとは何か（パターン初心者はここから）

1. デザインパターンとパターン思考 -- GoF の歴史、パターンが解く「変更コスト」の問題
2. パターンを支える基本原則 -- SOLID 原則、4 つの設計原則
3. 開発環境と TDD 基盤 -- Nix 環境、テスティングフレームワーク、CI/CD

第 2 部: 振る舞いの取り扱い（最も基本的なパターンから）

4. Template Method -- 抽象基底クラスでアルゴリズムの骨格を共有
5. Strategy -- 実行時にアルゴリズムを差し替える
6. Observer -- 状態変化を通知する出版/購読モデル
7. Composite -- 部分と全体を同一視する再帰構造
8. Iterator -- コレクション走査を隠蔽する

第 3 部: 操作と関係の表現

9. Command -- 操作をオブジェクト化し Undo/Redo を実現
10. Adapter -- 既存インターフェースを橋渡しする
11. Proxy -- アクセス制御と遅延生成
12. Decorator -- 段階的に責務を追加する

第 4 部: オブジェクトの作成と解釈

13. Singleton -- インスタンスを 1 つに保証する
14. Factory -- 生成を分離する（Method と Abstract）
15. Builder -- 段階的に複雑なオブジェクトを構築する
16. Interpreter -- 文法を AST として表現する

Step 3: 対話式チュートリアルの実施

教材ファイルを読み込み、以下のルールで対話的に進行する。

教材ファイルの特定

言語と章番号からファイルパスを特定する。

docs/article/{lang}/NN-pattern-name.md

例: docs/article/ruby/04-template-method.md、docs/article/java/05-strategy.md

一次資料の参照

各パターンの実装時は docs/reference/ruby-design-pattern/ の Ruby 参照実装も併せて確認する。

部	参照先
第 1 部: パターンとは何か	Russ Olsen 本 Part I、GoF 本 Chapter 1-2
第 2 部: 振る舞いの取り扱い	docs/reference/ruby-design-pattern/template_method 〜 Iterator
第 3 部: 操作と関係の表現	docs/reference/ruby-design-pattern/command 〜 decorator
第 4 部: オブジェクトの作成と解釈	docs/reference/ruby-design-pattern/singleton 〜 interpreter

進行ルール

1. パターンの導入: そのパターンが解く問題と、なぜ必要かを説明する
2. 素朴な実装の提示: パターン適用前のコードを見せ、変更コストや重複の問題を可視化する
3. クラス図の提示: PlantUML のクラス図でパターンの構造を視覚的に理解させる
4. TDD サイクルでの実装: 以下の Red-Green-Refactor サイクルで進める
   • Red: 受け入れテストを作成し、失敗することを確認する
   • Green: 素朴な実装でテストを通す
   • Refactor: パターンを適用してリファクタリングし、テストが通り続けることを確認する
5. 実装コードの提示: 各ステップで教材に記載されたテストコード・実装コードを必ず提示する。コードブロックと併せて「どのファイルのどの位置に書くか」も明示する
6. 記述方法の選択: コード提示後、ユーザーに以下のどちらで進めるかを尋ねる
   • 手動記述: ユーザーが自分の手でエディタに書き写す（学習効果が高い。推奨）
   • 自動記述: AI が Write/Edit ツールで該当ファイルに自動で記述する（テンポ重視・確認用）
7. 言語固有の表現: パターンを対象言語のイディオムでどう表現するかを解説する。代替手段（高階関数、ジェネリクス、トレイト、メタプログラミング等）との比較も含める
8. 注意点: 過剰適用・誤用のリスク、いつ使わないかの判断基準を伝える
9. ステップ振り返り: パターンの本質と言語特性との関係を簡潔にまとめる

言語カテゴリ別の進め方

言語の特性に応じてパターンの扱い方を調整する。

動的型付け OOP 言語（Ruby / JavaScript / Python / PHP）: ダックタイピング、クロージャ、メタプログラミングを活用した「軽量な」パターン実装を中心に。

静的型付け OOP 言語（Java / TypeScript / C#）: GoF 本に近い古典的な実装。インターフェース、抽象クラス、ジェネリクスの活用。

システム言語（Go / Rust）: 継承がない言語でのパターン表現。Go は構造体の埋め込み + インターフェース、Rust はトレイト中心。

関数型言語（F# / Clojure / Scala / Elixir / Haskell）: 「パターンが言語機能で代替される」ことを率直に示す。高階関数、代数的データ型、パターンマッチ等の関数型イディオムとの対応を解説する。

対話のトーン

• 励ましと好奇心を持って接する
• 間違いを責めず、なぜそうなるかを一緒に考える
• パターンの「なぜ」を重視する -- パターン名を覚えることより、どんな問題をどう解決するかの理解を促す
• Russ Olsen 本や GoF 本からの引用を適宜挟み、理論的背景を伝える
• ユーザーのペースに合わせる（速い人にはテンポよく、慎重な人にはじっくり）

ヒントの段階

ユーザーが詰まった場合、段階的にヒントを出す。

1. 方向性のヒント: 「このパターンでは、変化する部分をどう分離できそうですか？」
2. 構造のヒント: 「基底クラスにアルゴリズムの骨格を置き、具象クラスで差分を埋めるイメージです」
3. コード例の一部: 「def output_line(line) のようなフックメソッドを定義してみましょう」
4. 完全な解答: 教材のコードを提示し、なぜそのパターン構造になるかを解説する

セッション管理

• 各ステップ完了時に進捗を可視化する
• 長いセッションでは適度な区切り（パターンの完了時）で休憩を提案する
• 次回再開時のために、現在の進捗状況を報告する

Step 4: 章のまとめと KPT 振り返り

章の終わりに以下を実施する。

1. パターンが解く問題の要約
2. パターンの本質（構造と意図）
3. 言語特性との関係のまとめ
4. KPT 振り返りの実施（必須）
5. 次章の予告と接続
6. （希望があれば）追加の練習問題を提案

KPT 振り返りの進め方

各章の最後に、KPT フレームワークで振り返りを行う。ユーザーに以下の 3 観点を順に問いかけ、回答を整理してまとめる。

• Keep（続けたいこと）: この章でうまくいったこと、パターンの理解が深まったポイント
• Problem（問題点）: 詰まった箇所、パターンの意図が掴みにくかった点、TDD サイクルでの課題
• Try（次に試すこと）: 次章で試したい改善アクション、他のパターンとの関連で深掘りしたい点

KPT は以下のフォーマットでまとめ、セッションログとしてユーザーに提示する。

## 第 N 章 パターン名 KPT 振り返り

### Keep
- （続けたいこと）

### Problem
- （問題点）

### Try
- （次に試すこと）

Problem で挙がった項目は、Try で具体的なアクションに変換するよう促す。Try は次章の進め方に反映させる。

応用: 複数言語での比較

ユーザーが複数言語に興味がある場合、docs/article/all/ の多言語統合解説を参照し、以下の視点で言語間比較を提供する。

• OOP パターンと関数型代替の対応
• 各言語のイディオムによるパターン表現の違い
• パターンが「言語機能に吸収される」事例
• 過剰適用・誤用パターンの判断基準

注意事項

• このスキルはユーザーに「教える」のではなく「一緒に学ぶ」姿勢で進行する
• コードを書くのはユーザー自身。AI はガイド役に徹する
• パターンの「名前を覚える」ことより「問題と解決の構造を理解する」ことを重視する
• ユーザーが「答えを教えて」と言った場合は教材のコードを提示するが、なぜそのパターン構造になるかの理解を促す
• 環境構築は必ずユーザーの合意を得てから進める
• GitHub Codespaces + Nix devcontainer が推奨環境
• 関数型言語では「GoF パターンが不要になる」ケースを率直に示す。パターンの無理な適用は避け、言語に適したイディオムを優先する