@k2works/claude-code-booster 3.0.0 → 3.1.0

package/lib/assets/docs/article/getting-start-tdd/rust/05-package-management-and-static-analysis.md

@@ -0,0 +1,212 @@
+# 第 5 章: パッケージ管理と静的解析
+
+## 5.1 はじめに
+
+前章では Conventional Commits によるコミットメッセージの規約を学びました。この章では、**パッケージ管理** と **静的コード解析** を導入し、コードの品質を自動でチェックできるようにします。
+
+## 5.2 Cargo によるパッケージ管理
+
+### Cargo とは
+
+> Cargo は Rust のパッケージマネージャ兼ビルドシステムです。プロジェクトの作成、ビルド、テスト、依存関係の管理、パッケージの公開まで、Rust 開発のあらゆる面をサポートします。
+
+Java の Gradle、Node の npm（package.json）、Python の uv、Ruby の Bundler（Gemfile）、Go の Go Modules に相当するのが Cargo です。
+
+### Cargo.toml の構成
+
+本プロジェクトの `Cargo.toml` は以下のようになっています。
+
+```toml
+[package]
+name = "fizzbuzz"
+version = "0.1.0"
+edition = "2021"
+```
+
+Rust の標準ライブラリ（`std::io`、`std::fmt` など）はインポートの `use` 宣言だけで利用でき、`Cargo.toml` への追加は不要です。
+
+### 主要なコマンド
+
+| コマンド | 説明 |
+|---------|------|
+| `cargo new <name>` | 新しいプロジェクトを作成 |
+| `cargo build` | プロジェクトをビルド |
+| `cargo test` | テストを実行 |
+| `cargo run` | バイナリを実行 |
+| `cargo add <crate>` | 依存クレートを追加 |
+| `cargo update` | 依存クレートを更新 |
+
+### Cargo の特徴
+
+- **`Cargo.lock` による再現性** — 依存クレートのバージョンを固定し、チーム全員が同じ環境で開発できる
+- **ワークスペース** — 複数クレートを 1 つのプロジェクトで管理
+- **`target/` ディレクトリ** — Node の `node_modules/`、Python の `.venv/` に相当（`.gitignore` に追加）
+
+## 5.3 Clippy による静的解析
+
+### Clippy とは
+
+> Clippy は Rust の公式リンターです。コードの品質を向上させるための数百のルール（lint）を提供し、一般的なミスやアンチパターンを検出します。
+
+Ruby の RuboCop、Java の Checkstyle + PMD、TypeScript の ESLint、Python の Ruff、Go の golangci-lint に相当するツールです。
+
+### 実行してみる
+
+```bash
+$ cargo clippy -- -D warnings
+```
+
+`-D warnings` オプションを付けることで、警告をエラーとして扱い、CI で確実にチェックできます。
+
+### Clippy のカテゴリ
+
+| カテゴリ | 説明 |
+|---------|------|
+| `clippy::correctness` | バグになりうるコード（デフォルト有効） |
+| `clippy::style` | 慣用的でないコードスタイル |
+| `clippy::complexity` | 不必要に複雑なコード |
+| `clippy::perf` | パフォーマンスに影響するコード |
+| `clippy::pedantic` | より厳密なチェック（オプトイン） |
+
+## 5.4 rustfmt によるコードフォーマット
+
+### rustfmt とは
+
+> rustfmt は Rust の公式コードフォーマッターです。コードスタイルを統一し、チーム内のスタイル議論を排除します。
+
+Go の gofmt、Python の Ruff format、TypeScript の Prettier、Ruby の RuboCop --auto-correct に相当します。
+
+### 実行してみる
+
+```bash
+# フォーマットチェック（CI 向け）
+$ cargo fmt --check
+
+# 自動フォーマット
+$ cargo fmt
+```
+
+### コードスタイル例
+
+rustfmt はデフォルトで以下のスタイルを適用します。
+
+```rust
+// Before（手動フォーマット）
+fn generate(number:i32)->String{
+match(number%3,number%5){(0,0)=>"FizzBuzz".to_string(),(0,_)=>"Fizz".to_string(),(_, 0)=>"Buzz".to_string(),_=>number.to_string(),}
+}
+
+// After（rustfmt 適用後）
+fn generate(number: i32) -> String {
+    match (number % 3, number % 5) {
+        (0, 0) => "FizzBuzz".to_string(),
+        (0, _) => "Fizz".to_string(),
+        (_, 0) => "Buzz".to_string(),
+        _ => number.to_string(),
+    }
+}
+```
+
+## 5.5 Clippy によるコード複雑度チェック
+
+### 認知的複雑度（Cognitive Complexity）
+
+Clippy には `cognitive_complexity` lint が内蔵されており、関数の複雑度を計測できます。
+
+> 認知的複雑度とは、コードがどれだけ理解しにくいかを数値化した指標です。循環的複雑度（Cyclomatic Complexity）と異なり、ネストの深さやフロー制御の読みにくさも考慮します。
+
+| 複雑度の範囲 | 意味 |
+|-------------|------|
+| 1〜7 | 低複雑度: 管理しやすく、問題なし |
+| 8〜15 | 中程度の複雑度: リファクタリングを検討 |
+| 16〜25 | 高複雑度: リファクタリングが強く推奨される |
+| 26 以上 | 非常に高い複雑度: 関数を分割する必要がある |
+
+### clippy.toml による閾値設定
+
+プロジェクトルートに `clippy.toml` を作成し、閾値を設定します。
+
+```toml
+cognitive-complexity-threshold = 7
+```
+
+他言語の複雑度チェック（PHP の PHPMD `reportLevel: 7`、Python の Ruff `max-complexity = 7`、TypeScript の ESLint `complexity: ["error", { max: 7 }]`）と同じ基準値 **7** を設定します。
+
+### lib.rs での有効化
+
+`lib.rs` にアトリビュートを追加して、プロジェクト全体で複雑度チェックを有効化します。
+
+```rust
+#![warn(clippy::cognitive_complexity)]
+
+pub mod application;
+pub mod domain;
+pub mod fizz_buzz;
+```
+
+### 実行してみる
+
+```bash
+# 複雑度チェック（警告をエラーとして扱う）
+$ cargo clippy -- -D clippy::cognitive_complexity
+```
+
+現在の FizzBuzz 実装では、各メソッドが短く単純なため、閾値 7 を超える関数はありません。
+
+### justfile への追加
+
+```just
+# 複雑度チェック
+complexity:
+    cargo clippy -- -D clippy::cognitive_complexity
+
+# 全チェック実行（フォーマット → 静的解析 → 複雑度 → テスト）
+check: fmt-check lint complexity test
+```
+
+`just complexity` で複雑度チェックを単独実行、`just check` で全品質チェックをまとめて実行できます。
+
+### 他言語との比較
+
+| 言語 | 複雑度チェックツール | 設定 |
+|------|---------------------|------|
+| Rust | Clippy（cognitive_complexity） | `clippy.toml: cognitive-complexity-threshold = 7` |
+| PHP | PHPMD | `reportLevel: 7` |
+| Java | PMD | `CyclomaticComplexity` |
+| Python | Ruff（McCabe） | `max-complexity = 7` |
+| TypeScript | ESLint | `complexity: ["error", { max: 7 }]` |
+| Ruby | RuboCop | `Metrics/CyclomaticComplexity` |
+| Go | golangci-lint（gocyclo） | デフォルト設定 |
+
+Rust の Clippy は PHP の PHPMD や Go の golangci-lint と異なり、**標準ツールチェーンに内蔵**されているため、追加インストールが不要です。
+
+## 5.6 コードカバレッジ
+
+### cargo-tarpaulin
+
+Rust のカバレッジツールとして `cargo-tarpaulin` があります。
+
+```bash
+# インストール（任意）
+$ cargo install cargo-tarpaulin
+
+# カバレッジ計測
+$ cargo tarpaulin --out stdout
+```
+
+!!! note "カバレッジの代替手段"
+    cargo-tarpaulin は Linux 環境向けです。macOS では `cargo llvm-cov` が利用できます。Nix 環境ではインストールが必要な場合があるため、テスト網羅率で代替することも可能です。
+
+## 5.7 まとめ
+
+この章では以下を導入しました。
+
+| ツール | 役割 | 他言語の対応ツール |
+|--------|------|-------------------|
+| Cargo | パッケージ管理・ビルド | npm, Bundler, Go Modules, Gradle |
+| Clippy | 静的解析（リンター） | ESLint, RuboCop, golangci-lint, Ruff |
+| Clippy（cognitive_complexity） | コード複雑度チェック | PHPMD, PMD, Ruff McCabe, ESLint complexity |
+| rustfmt | コードフォーマット | Prettier, gofmt, RuboCop --auto-correct |
+| cargo-tarpaulin | カバレッジ計測 | c8, SimpleCov, go test -cover |
+
+次章では、これらのツールを **タスクランナー**（just）でまとめて実行できるようにし、**CI/CD** パイプラインを構築します。

package/lib/assets/docs/article/getting-start-tdd/rust/06-task-runner-and-ci-cd.md

@@ -0,0 +1,164 @@
+# 第 6 章: タスクランナーと CI/CD
+
+## 6.1 はじめに
+
+前章では静的コード解析ツールとコードフォーマッターを導入しました。テストの実行、静的解析、フォーマットチェックと、様々なコマンドを使えるようになりましたが、毎回それぞれのコマンドを覚えて実行するのは面倒です。
+
+この章では **タスクランナー** を使ってこれらのタスクをまとめて実行できるようにし、さらに **CI/CD** パイプラインを構築します。
+
+## 6.2 just によるタスク管理
+
+### just とは
+
+> [just](https://github.com/casey/just) は Rust 製のコマンドランナーです。Makefile に似た構文でタスク（レシピ）を定義し、`just <レシピ名>` で実行できます。Makefile と異なりファイルのビルドではなく **コマンド実行に特化** しており、タブ／スペースの混在を許容し、エラーメッセージもわかりやすいのが特徴です。
+
+Ruby の Rake、Java の Gradle、Node の npm scripts、Python の tox、Go プロジェクトでの Makefile に相当します。Rust エコシステムでは Rust 製ということもあり、just がタスクランナーとして広く採用されています。
+
+### justfile の定義
+
+```just
+# Rust プロジェクトのタスクランナー
+
+# テスト実行
+test:
+    cargo test
+
+# Clippy による静的解析
+lint:
+    cargo clippy -- -D warnings
+
+# 複雑度チェック
+complexity:
+    cargo clippy -- -D clippy::cognitive_complexity
+
+# コードフォーマット
+fmt:
+    cargo fmt
+
+# フォーマットチェック
+fmt-check:
+    cargo fmt --check
+
+# 全チェック実行（フォーマット → 静的解析 → 複雑度 → テスト）
+check: fmt-check lint complexity test
+
+# リリースビルド
+build:
+    cargo build --release
+
+# 実行
+run:
+    cargo run
+
+# ビルド成果物の削除
+clean:
+    cargo clean
+```
+
+### 主要なタスク
+
+| タスク | コマンド | 説明 |
+|--------|---------|------|
+| `just test` | `cargo test` | テスト実行 |
+| `just lint` | `cargo clippy -- -D warnings` | Clippy による静的解析 |
+| `just complexity` | `cargo clippy -- -D clippy::cognitive_complexity` | 複雑度チェック |
+| `just fmt` | `cargo fmt` | コードフォーマット |
+| `just fmt-check` | `cargo fmt --check` | フォーマットチェック |
+| `just check` | fmt-check → lint → complexity → test | 全チェック実行 |
+| `just build` | `cargo build --release` | リリースビルド |
+| `just clean` | `cargo clean` | ビルド成果物の削除 |
+
+### 実行例
+
+```bash
+# 全チェック実行
+$ just check
+cargo fmt --check
+cargo clippy -- -D warnings
+cargo clippy -- -D clippy::cognitive_complexity
+cargo test
+test result: ok. 12 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
+```
+
+## 6.3 GitHub Actions による CI/CD
+
+### CI/CD とは
+
+> CI/CD（Continuous Integration / Continuous Delivery）は、コードの変更を自動的にビルド、テスト、デプロイするプラクティスです。
+
+### ワークフローの定義
+
+`.github/workflows/rust-ci.yml` にワークフローを定義します。
+
+```yaml
+name: Rust CI
+
+on:
+  push:
+    branches: [main, develop]
+    paths:
+      - "apps/rust/**"
+      - ".github/workflows/rust-ci.yml"
+  pull_request:
+    branches: [main]
+    paths:
+      - "apps/rust/**"
+
+permissions:
+  contents: read
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout the repository
+        uses: actions/checkout@v4
+
+      - name: Install Nix
+        uses: cachix/install-nix-action@v30
+        with:
+          nix_path: nixpkgs=channel:nixos-unstable
+
+      - name: Cache Nix store
+        uses: actions/cache@v4
+        with:
+          path: /tmp/nix-cache
+          key: ${{ runner.os }}-nix-rust-${{ hashFiles('flake.lock', 'ops/nix/environments/rust/shell.nix') }}
+          restore-keys: |
+            ${{ runner.os }}-nix-rust-
+
+      - name: Run all checks
+        run: nix develop .#rust --command bash -c "cd apps/rust && just check"
+```
+
+### CI パイプラインの流れ
+
+```
+Push / PR → just check（fmt-check → lint → complexity → test）→ 結果通知
+```
+
+## 6.4 他言語との比較
+
+| 言語 | タスクランナー | CI ツール | テスト | 静的解析 | フォーマット |
+|------|-------------|----------|--------|---------|------------|
+| Rust | just | GitHub Actions | cargo test | Clippy | rustfmt |
+| Go | Makefile | GitHub Actions | go test | golangci-lint | gofmt |
+| Java | Gradle | GitHub Actions | JUnit | Checkstyle + PMD | Checkstyle |
+| Python | tox | GitHub Actions | pytest | Ruff | Ruff |
+| Node | npm scripts | GitHub Actions | Vitest | ESLint | Prettier |
+| Ruby | Rake | GitHub Actions | Minitest | RuboCop | RuboCop |
+| PHP | Composer scripts | GitHub Actions | PHPUnit | PHP_CodeSniffer + PHPStan | phpcbf |
+
+## 6.5 まとめ
+
+この章では以下を実現しました。
+
+| 項目 | 内容 |
+|------|------|
+| justfile | test / lint / complexity / fmt / check タスクを定義 |
+| `just check` | フォーマットチェック → Clippy → 複雑度 → テストを一括実行 |
+| GitHub Actions | push / PR 時に `just check` で CI を実行 |
+| Nix 統合 | CI でも `nix develop .#rust` を使用し環境を統一 |
+
+第 2 部を通じて、ソフトウェア開発の三種の神器（バージョン管理、テスティング、自動化）を Rust の開発環境に整備しました。just は Rust 製のコマンドランナーであり、Rust エコシステムとの親和性が高く、Makefile よりもシンプルにタスクを定義できます。次の第 3 部では、オブジェクト指向設計（struct、trait、デザインパターン）に進みます。

package/lib/assets/docs/article/getting-start-tdd/rust/07-encapsulation-and-polymorphism.md

@@ -0,0 +1,142 @@
+# 第 7 章: カプセル化とポリモーフィズム
+
+## 7.1 はじめに
+
+第 1 部では手続き型の FizzBuzz プログラムを TDD で構築しました。この章からは **オブジェクト指向プログラミング** の要素を Rust で実現していきます。まず **カプセル化** と **ポリモーフィズム** を導入し、手続き型コードを構造化された設計に進化させます。
+
+## 7.2 手続き型コードの課題
+
+第 1 部で作成した `generate` 関数は手続き型プログラミングの典型例です。
+
+```rust
+pub fn generate(number: i32) -> String {
+    match (number % 3, number % 5) {
+        (0, 0) => "FizzBuzz".to_string(),
+        (0, _) => "Fizz".to_string(),
+        (_, 0) => "Buzz".to_string(),
+        _ => number.to_string(),
+    }
+}
+```
+
+この設計の課題は、新しい FizzBuzz タイプ（数値のみ返す、FizzBuzz のみ返す等）を追加する場合に、既存の関数を直接修正する必要があることです。
+
+## 7.3 カプセル化 — 値オブジェクトの導入
+
+### FizzBuzzValue 構造体
+
+数値と FizzBuzz の結果をまとめた値オブジェクトを作成します。
+
+```rust
+#[derive(Debug, Clone, PartialEq)]
+pub struct FizzBuzzValue {
+    number: i32,
+    value: String,
+}
+
+impl FizzBuzzValue {
+    pub fn new(number: i32, value: String) -> Self {
+        Self { number, value }
+    }
+
+    pub fn number(&self) -> i32 {
+        self.number
+    }
+
+    pub fn value(&self) -> &str {
+        &self.value
+    }
+}
+
+impl std::fmt::Display for FizzBuzzValue {
+    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
+        write!(f, "{}", self.value)
+    }
+}
+```
+
+Rust ではフィールドをデフォルトで非公開（private）にし、メソッド経由でアクセスする設計が標準です。`#[derive(Debug, Clone, PartialEq)]` は Go の手動実装や Java の `equals`/`hashCode` に相当する機能を自動生成します。
+
+## 7.4 ポリモーフィズム — トレイトの導入
+
+### FizzBuzzType トレイト
+
+FizzBuzz のタイプを抽象化するトレイトを定義します。
+
+```rust
+pub trait FizzBuzzType {
+    fn generate(&self, number: i32) -> FizzBuzzValue;
+}
+```
+
+### 3 つの実装
+
+```rust
+// タイプ 1: 通常の FizzBuzz
+pub struct FizzBuzzType01;
+impl FizzBuzzType for FizzBuzzType01 {
+    fn generate(&self, number: i32) -> FizzBuzzValue {
+        let value = match (number % 3, number % 5) {
+            (0, 0) => "FizzBuzz".to_string(),
+            (0, _) => "Fizz".to_string(),
+            (_, 0) => "Buzz".to_string(),
+            _ => number.to_string(),
+        };
+        FizzBuzzValue::new(number, value)
+    }
+}
+
+// タイプ 2: 数値のみ
+pub struct FizzBuzzType02;
+impl FizzBuzzType for FizzBuzzType02 {
+    fn generate(&self, number: i32) -> FizzBuzzValue {
+        FizzBuzzValue::new(number, number.to_string())
+    }
+}
+
+// タイプ 3: FizzBuzz のみ（Fizz/Buzz/FizzBuzz 以外は空文字）
+pub struct FizzBuzzType03;
+impl FizzBuzzType for FizzBuzzType03 {
+    fn generate(&self, number: i32) -> FizzBuzzValue {
+        let value = match (number % 3, number % 5) {
+            (0, 0) => "FizzBuzz".to_string(),
+            (0, _) => "Fizz".to_string(),
+            (_, 0) => "Buzz".to_string(),
+            _ => String::new(),
+        };
+        FizzBuzzValue::new(number, value)
+    }
+}
+```
+
+`trait` は Java の `interface` や Go の暗黙的インターフェースに相当しますが、Rust では `impl Trait for Struct` で明示的に実装します。
+
+## 7.5 ファクトリ関数
+
+タイプ番号から適切な実装を返すファクトリ関数を作成します。
+
+```rust
+pub fn create(type_number: i32) -> Result<Box<dyn FizzBuzzType>, String> {
+    match type_number {
+        1 => Ok(Box::new(FizzBuzzType01)),
+        2 => Ok(Box::new(FizzBuzzType02)),
+        3 => Ok(Box::new(FizzBuzzType03)),
+        _ => Err(format!("タイプ{}は見つかりません", type_number)),
+    }
+}
+```
+
+`Box<dyn FizzBuzzType>` はトレイトオブジェクトで、Java の `FizzBuzzType` インターフェース型や Go の `interface{}` に相当します。`Result` 型で不正なタイプ番号のエラーハンドリングも行います。
+
+## 7.6 まとめ
+
+この章では以下を学びました。
+
+| 概念 | Rust の実現方法 | 他言語の対応 |
+|------|---------------|-------------|
+| カプセル化 | `struct` + 非公開フィールド + メソッド | Java: private + getter |
+| ポリモーフィズム | `trait` + `impl Trait for Struct` | Java: interface |
+| 値オブジェクト | `#[derive(PartialEq)]` + 不変フィールド | Java: equals/hashCode |
+| ファクトリ | `Result<Box<dyn Trait>>` | Java: Factory Method |
+
+次章では、デザインパターン（Command、First-Class Collection）を適用していきます。

package/lib/assets/docs/article/getting-start-tdd/rust/08-design-patterns.md

@@ -0,0 +1,145 @@
+# 第 8 章: デザインパターンの適用
+
+## 8.1 はじめに
+
+前章では struct と trait を使ってカプセル化とポリモーフィズムを実現しました。この章では **デザインパターン** を適用して、設計をさらに改善します。
+
+## 8.2 Value Object パターン
+
+### FizzBuzzValue の強化
+
+前章で作成した `FizzBuzzValue` は既に Value Object パターンを実現しています。
+
+```rust
+#[derive(Debug, Clone, PartialEq)]
+pub struct FizzBuzzValue {
+    number: i32,
+    value: String,
+}
+```
+
+`#[derive(PartialEq)]` により、2 つの `FizzBuzzValue` を値で比較できます。`Clone` により値のコピーが可能です。Rust の所有権システムにより、Value Object の不変性が自然に保証されます。
+
+## 8.3 First-Class Collection パターン
+
+### FizzBuzzList 構造体
+
+FizzBuzzValue のコレクションを専用の型でラップします。
+
+```rust
+pub struct FizzBuzzList {
+    list: Vec<FizzBuzzValue>,
+}
+
+impl FizzBuzzList {
+    const MAX_COUNT: usize = 100;
+
+    pub fn new(fizz_buzz_type: &dyn FizzBuzzType) -> Self {
+        let list = (1..=Self::MAX_COUNT as i32)
+            .map(|n| fizz_buzz_type.generate(n))
+            .collect();
+        Self { list }
+    }
+
+    pub fn value(&self) -> &[FizzBuzzValue] {
+        &self.list
+    }
+
+    pub fn len(&self) -> usize {
+        self.list.len()
+    }
+
+    pub fn is_empty(&self) -> bool {
+        self.list.is_empty()
+    }
+}
+
+impl std::fmt::Display for FizzBuzzList {
+    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
+        let values: Vec<String> = self.list.iter().map(|v| v.value().to_string()).collect();
+        write!(f, "{}", values.join("\n"))
+    }
+}
+```
+
+First-Class Collection パターンにより、コレクション操作の責務を `FizzBuzzList` に集約できます。`MAX_COUNT` は定数として定義し、マジックナンバーを排除します。
+
+## 8.4 Command パターン
+
+### FizzBuzzCommand トレイト
+
+FizzBuzz の操作をコマンドとして抽象化します。
+
+```rust
+pub trait FizzBuzzCommand {
+    fn execute(&self) -> String;
+}
+```
+
+### 単一値コマンド
+
+```rust
+pub struct FizzBuzzValueCommand {
+    fizz_buzz_type: Box<dyn FizzBuzzType>,
+    number: i32,
+}
+
+impl FizzBuzzValueCommand {
+    pub fn new(type_number: i32, number: i32) -> Result<Self, String> {
+        let fizz_buzz_type = create(type_number)?;
+        Ok(Self { fizz_buzz_type, number })
+    }
+}
+
+impl FizzBuzzCommand for FizzBuzzValueCommand {
+    fn execute(&self) -> String {
+        self.fizz_buzz_type.generate(self.number).to_string()
+    }
+}
+```
+
+### リストコマンド
+
+```rust
+pub struct FizzBuzzListCommand {
+    fizz_buzz_type: Box<dyn FizzBuzzType>,
+}
+
+impl FizzBuzzListCommand {
+    pub fn new(type_number: i32) -> Result<Self, String> {
+        let fizz_buzz_type = create(type_number)?;
+        Ok(Self { fizz_buzz_type })
+    }
+}
+
+impl FizzBuzzCommand for FizzBuzzListCommand {
+    fn execute(&self) -> String {
+        let list = FizzBuzzList::new(self.fizz_buzz_type.as_ref());
+        list.to_string()
+    }
+}
+```
+
+`?` 演算子は `Result` のエラーを自動的に伝播させる Rust のイディオムです。Java の例外伝播や Go の `if err != nil { return err }` パターンに相当します。
+
+## 8.5 他言語との比較
+
+| パターン | Java | Go | Rust |
+|---------|------|------|------|
+| Value Object | `equals`/`hashCode` 手動実装 | 構造体比較（手動） | `#[derive(PartialEq)]` |
+| First-Class Collection | クラスで `List<T>` をラップ | 構造体でスライスをラップ | 構造体で `Vec<T>` をラップ |
+| Command | `interface` + クラス | `interface` + 構造体 | `trait` + 構造体 |
+| Factory | `static` メソッド | 関数 | 関数 + `Result<Box<dyn Trait>>` |
+
+## 8.6 まとめ
+
+この章では以下のデザインパターンを適用しました。
+
+| パターン | 目的 | Rust の実現方法 |
+|---------|------|---------------|
+| Value Object | 値の等価性保証 | `#[derive(PartialEq, Clone)]` |
+| First-Class Collection | コレクション操作の集約 | `struct` + `Vec<T>` |
+| Command | 操作の抽象化と遅延実行 | `trait` + `Box<dyn Trait>` |
+| Factory Method | 型番号による生成 | `match` + `Result<Box<dyn Trait>>` |
+
+次章では SOLID 原則の観点から設計を評価し、モジュール分割を行います。