npm - @k2works/claude-code-booster - Versions diffs - 6.1.0 → 6.3.0 - Mend

@k2works/claude-code-booster 6.1.0 → 6.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (622) hide show

package/lib/assets/docs/article/functional-desgin-ppp/all/index.md DELETED Viewed

@@ -1,388 +0,0 @@
-# 関数型デザイン - 原則、パターン、実践：多言語統合解説
-本記事シリーズは、6 つの関数型言語（Clojure, Scala, Elixir, F#, Haskell, Rust）での実装を横断的に比較し、関数型デザインパターンの**本質**と**言語固有の表現**を統合的に解説します。
-## 本シリーズの目的
-各言語の個別記事は「その言語でどう実装するか」に焦点を当てています。本統合記事は、それらを横断して以下を明らかにします：
-- **共通の本質**: 言語を超えて成り立つ関数型デザインの原則
-- **言語間の差異**: 型システム、実行モデル、イディオムの違いが設計にどう影響するか
-- **選択の指針**: どの言語特性がどのパターンに適しているか
-## 言語特性マトリクス
-| 特性 | Clojure | Scala | Elixir | F# | Haskell | Rust |
-|------|---------|-------|--------|-----|---------|------|
-| 型システム | 動的 | 静的（強い） | 動的 | 静的（推論） | 静的（純粋） | 静的（所有権） |
-| 多態性 | マルチメソッド / プロトコル | trait / パターンマッチ | プロトコル / ビヘイビア | 判別共用体 / インターフェース | 型クラス | trait / enum |
-| 不変性 | デフォルト不変 | case class | デフォルト不変 | デフォルト不変 | 完全不変 | デフォルト不変 |
-| 並行処理 | STM / Agent | Future / Akka | OTP / GenServer | Async / MailboxProcessor | STM / MVar | async / Mutex / Channel |
-| 実行環境 | JVM | JVM | BEAM | .NET | GHC | ネイティブ |
-## 記事構成
-### 第 1 部: 関数型プログラミングの基礎原則
-| 章 | 統合記事 | テーマ | 比較のポイント |
-|----|---------|--------|---------------|
-| 1 | [不変性とデータ変換](./01-immutability-and-data-transformation.md) | 不変データ構造と変換パイプライン | 構造共有の実装差異、コピーコスト、永続データ構造 |
-| 2 | [関数合成と高階関数](./02-function-composition.md) | 関数の組み合わせによる抽象化 | カリー化のデフォルト有無、パイプ演算子、合成演算子 |
-| 3 | [多態性の実現方法](./03-polymorphism.md) | 型に基づく振る舞いの切り替え | アドホック多態性 vs サブタイプ多態性、式問題への対応 |
-#### 主な言語間比較テーマ
-- **不変性の保証レベル**: Haskell の完全不変 vs Rust の `mut` オプトイン vs Clojure のデフォルト不変
-- **データ変換スタイル**: Clojure のスレッディングマクロ vs Elixir のパイプ演算子 vs Haskell の関数合成
-- **多態性メカニズム**: Clojure マルチメソッド vs Haskell 型クラス vs Rust trait vs Scala パターンマッチ
-### 第 2 部: 仕様とテスト
-| 章 | 統合記事 | テーマ | 比較のポイント |
-|----|---------|--------|---------------|
-| 4 | [データ検証](./04-data-validation.md) | データの正しさを保証する手法 | 型レベル検証 vs ランタイム検証、Clojure Spec の独自性 |
-| 5 | [プロパティベーステスト](./05-property-based-testing.md) | 性質に基づく自動テスト生成 | 各言語の PBT ライブラリとジェネレータ設計 |
-| 6 | [TDD と関数型プログラミング](./06-tdd-and-functional.md) | テスト駆動開発の関数型アプローチ | 純粋関数のテスト容易性、副作用の分離戦略 |
-#### 主な言語間比較テーマ
-- **検証アプローチ**: Clojure Spec（ランタイム仕様） vs Haskell/F# の型レベル保証 vs Rust の型 + バリデーション
-- **PBT ライブラリ**: test.check vs ScalaCheck vs StreamData vs FsCheck vs QuickCheck vs proptest
-- **テスト設計**: 動的型付け言語のテスト戦略 vs 静的型付け言語のテスト戦略
-### 第 3 部: デザインパターン - 構造パターン
-| 章 | 統合記事 | テーマ | 比較のポイント |
-|----|---------|--------|---------------|
-| 7 | [Composite パターン](./07-composite-pattern.md) | 個と集合の統一的な扱い | 代数的データ型 vs プロトコル、再帰的データ構造の表現 |
-| 8 | [Decorator パターン](./08-decorator-pattern.md) | 機能の動的な追加 | 関数合成 vs ラッパー型、ミドルウェアパターン |
-| 9 | [Adapter パターン](./09-adapter-pattern.md) | インターフェースの変換 | プロトコル拡張 vs ニュータイプ vs trait 実装 |
-> **Elixir の章 7-10 について**: Elixir では OTP の特性を活かし、章 7-10 を Elixir 固有のテーマ（Effects、Error Handling、I/O、Concurrency Patterns）で構成しています。統合記事では GoF パターンの比較を主軸としつつ、Elixir の代替アプローチをコラムとして扱います。
-#### 主な言語間比較テーマ
-- **Composite**: Haskell/F# の代数的データ型 vs Scala の sealed trait vs Rust の enum
-- **Decorator**: Clojure の関数ラッピング vs Haskell のモナドトランスフォーマー vs Rust のトレイトオブジェクト
-- **Adapter**: 構造的型付け vs 名前的型付け、既存型への振る舞い追加手法
-### 第 4 部: デザインパターン - 振る舞いパターン
-| 章 | 統合記事 | テーマ | 比較のポイント |
-|----|---------|--------|---------------|
-| 10 | [Strategy パターン](./10-strategy-pattern.md) | アルゴリズムの交換可能性 | 高階関数 vs 型クラス vs trait オブジェクト |
-| 11 | [Command パターン](./11-command-pattern.md) | 操作のデータ化と Undo/Redo | データとしてのコマンド表現、イベントソーシングとの関連 |
-| 12 | [Visitor パターン](./12-visitor-pattern.md) | データ構造と操作の分離 | パターンマッチ vs ダブルディスパッチ、式問題 |
-#### 主な言語間比較テーマ
-- **Strategy**: 関数型では「高階関数に戦略を渡す」が自然 — 言語間で表現がどう異なるか
-- **Command**: 不変データとしてのコマンド、永続データ構造による自然な Undo
-- **Visitor**: Haskell/F#/Rust のパターンマッチで Visitor が不要になるケース
-### 第 5 部: デザインパターン - 生成パターン
-| 章 | 統合記事 | テーマ | 比較のポイント |
-|----|---------|--------|---------------|
-| 13 | [Abstract Factory パターン](./13-abstract-factory-pattern.md) | オブジェクトファミリーの一貫生成 | モジュール / 名前空間による分離 vs 型パラメータ |
-| 14 | [Abstract Server パターン](./14-abstract-server-pattern.md) | 依存関係逆転の原則 | プロトコル vs 型クラス vs trait、DI の関数型アプローチ |
-#### 主な言語間比較テーマ
-- **Factory**: 関数型での「生成」の意味 — コンストラクタ関数 vs ファクトリモジュール
-- **Abstract Server**: DIP を実現する各言語のメカニズム比較
-### 第 6 部: 実践的なケーススタディ
-| 章 | 統合記事                                                   | テーマ | 比較のポイント |
-|----|--------------------------------------------------------|--------|---------------|
-| 15 | [Gossiping Bus Drivers](./15-gossiping-bus-drivers.md) | シミュレーションの関数型設計 | 状態遷移の表現、無限シーケンス、集合演算 |
-| 16 | [給与計算システム](./16-payroll-system.md)                     | ドメインモデリング | ドメイン型の設計、ビジネスルールの表現 |
-| 17 | [レンタルビデオシステム](./17-video-rental-system.md)             | ポリシーパターンの適用 | 料金計算ロジック、フォーマッター設計 |
-| 18 | [並行処理システム](./18-concurrency-system.md)                 | 並行処理の設計 | 各言語の並行処理モデルの根本的な違い |
-| 19 | [Wa-Tor シミュレーション](./19-wa-tor-simulation.md)           | セルオートマトンの実装 | 2D グリッドの不変表現、並行更新戦略 |
-#### 主な言語間比較テーマ
-- **並行処理モデル**: Clojure STM vs Elixir OTP vs Haskell STM vs Rust 所有権ベース vs Scala Akka
-- **ドメインモデリング**: 動的型付け（マップベース） vs 静的型付け（代数的データ型）
-- **シミュレーション**: 状態更新の純粋性、パフォーマンスと安全性のトレードオフ
-### 第 7 部: まとめと応用
-| 章 | 統合記事 | テーマ | 比較のポイント |
-|----|---------|--------|---------------|
-| 20 | [パターン間の相互作用](./20-pattern-interactions.md) | パターンの組み合わせ | 各言語での合成可能性、DSL 構築アプローチ |
-| 21 | [ベストプラクティス](./21-best-practices.md) | 関数型設計の指針 | 言語横断的なプラクティス vs 言語固有のイディオム |
-| 22 | [OO から FP への移行](./22-oo-to-fp-migration.md) | パラダイムの橋渡し | 各言語のマルチパラダイム度合い、移行の容易さ |
-#### 主な言語間比較テーマ
-- **合成可能性**: モナド合成（Haskell） vs パイプライン合成（Elixir） vs メソッドチェーン（Scala）
-- **移行戦略**: Scala/F# のマルチパラダイム vs Haskell/Clojure の純粋関数型
-## 各章の統合記事構成テンプレート
-各統合記事は以下の構成で執筆します：
-```
-1. はじめに
-   - テーマの概要と関数型での意義
-2. 共通の本質
-   - 言語を超えて成り立つ原則・パターンの核心
-3. 言語別実装比較
-   - 6 言語の代表的なコードを並べて比較
-   - 各言語のイディオムを活かした実装の違い
-4. 比較分析
-   - 型システムの影響
-   - パフォーマンス特性
-   - 表現力と簡潔さのトレードオフ
-5. 実践的な選択指針
-   - どの言語特性がこのパターンに最も適しているか
-   - プロジェクト要件に応じた選択基準
-6. まとめ
-   - 言語横断的な学び
-   - 各言語の個別記事へのリンク
-```
-## 執筆ルール
-### 1. 執筆フォーマット
-````markdown
-# 第N章：章タイトル
-## N.1 セクションタイトル
-本文...
-### ダイアグラム
-```plantuml
-@startuml
-...
-@enduml
-```
-### ER 図
-```plantuml
-@startuml
-entity "テーブル名" {
-  ...
-}
-@enduml
-```
-### 実装
-<details>
-<summary>SQL 実装</summary>
-```sql
-CREATE TABLE ...
-```
-</details>
-````
-### 2. リスト記述ルール
-タスク項目やリスト項目は、ラベル行の後に **1 行空けて** から記述します。
-**NG**:
-```markdown
-**受入条件**:
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
-- [ ] JWT トークンが無効化される
-```
-**OK**:
-```markdown
-**受入条件**:
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
-- [ ] JWT トークンが無効化される
-```
-## 執筆計画
-### 概要
-全 22 章の統合記事を、章ごとの統合難易度に基づき 4 つのイテレーションで執筆します。
-- **総ソース量**: 約 52,000 行（6 言語 × 22 章）
-- **統合記事数**: 22 本
-- **各記事の想定規模**: 400〜800 行
-### 難易度分類
-各章を言語間の構造一貫性・ボリューム差・内容の乖離度で分類しました。
-| 難易度 | 章数 | 特徴 |
-|--------|------|------|
-| Low | 6 章 | 全言語で構造が一貫、そのまま統合可能 |
-| Medium | 7 章 | 共通フレームワーク + 言語固有セクションが必要 |
-| High | 9 章 | Elixir の独立カリキュラムや大幅なボリューム差への対応が必要 |
-### イテレーション 1: 基礎原則（Low 難易度）
-**対象**: 第 1 部 全 3 章
-全言語でセクション構造が一貫しており、統合が最も容易です。
-| 章 | タイトル | 平均行数 | 統合方針 |
-|----|---------|---------|---------|
-| 01 | 不変性とデータ変換 | 351 | 共通概念を軸に、言語別の不変性保証レベルを比較 |
-| 02 | 関数合成と高階関数 | 387 | 理論を共通化、パイプ演算子・合成演算子の差異を対比 |
-| 03 | 多態性の実現方法 | 399 | マルチメソッド / 型クラス / trait / 判別共用体を横断比較 |
-**執筆順序**: 01 → 02 → 03
-**完了条件**:
-- [ ] 各章が統合記事構成テンプレートに準拠
-- [ ] 6 言語すべてのコード例を含む
-- [ ] 言語間の差異を比較分析セクションで解説
-### イテレーション 2: 仕様・テスト + ケーススタディ前半（Low〜Medium 難易度）
-**対象**: 第 2 部 全 3 章 + 第 6 部 前半 3 章
-| 章 | タイトル | 平均行数 | 難易度 | 統合方針 |
-|----|---------|---------|--------|---------|
-| 04 | データ検証 | 309 | Medium | Clojure Spec の独自性を別セクションで扱い、他 5 言語の型ベース検証と対比 |
-| 05 | プロパティベーステスト | 336 | Medium | PBT の共通原理を軸に、各言語のライブラリ（test.check / ScalaCheck / StreamData / FsCheck / QuickCheck / proptest）を比較 |
-| 06 | TDD と関数型 | 420 | Medium | TDD サイクルは共通、F# の詳細実装（687 行）は拡張セクションで対応 |
-| 15 | Gossiping Bus Drivers | 305 | Low | 全言語の実装を並列提示、状態遷移の表現方法を比較 |
-| 16 | 給与計算システム | 338 | Low | ドメインモデリングを共通化、型表現の違いを比較 |
-| 17 | レンタルビデオシステム | 342 | Low | 料金計算ロジックとフォーマッター設計の多様な実装を比較 |
-**執筆順序**: 15 → 16 → 17 → 04 → 05 → 06
-**完了条件**:
-- [ ] Low 難易度の 3 章が完成
-- [ ] Medium 難易度の 3 章で Clojure Spec・F# 拡張セクションを適切に分離
-- [ ] 各 PBT ライブラリの比較表を含む
-### イテレーション 3: デザインパターン（Medium〜High 難易度）
-**対象**: 第 3 部〜第 5 部 全 8 章
-Elixir の章 7-10 が独立カリキュラム（Effects / Error Handling / I/O / Concurrency）のため、統合設計に工夫が必要です。
-#### Elixir 分離戦略
-章 7-10 では以下の構成を採用します：
-1. **メイン**: 5 言語（Clojure, Scala, F#, Haskell, Rust）の GoF パターン比較
-2. **コラム**: Elixir の代替アプローチ（副作用・エラーハンドリング・I/O・並行処理）
-| 章 | タイトル | 平均行数 | 難易度 | 統合方針 |
-|----|---------|---------|--------|---------|
-| 07 | Composite パターン | 380 | High | 5 言語の Composite 比較 + Elixir コラム「副作用と純粋関数」 |
-| 08 | Decorator パターン | 345 | High | 5 言語の Decorator 比較 + Elixir コラム「エラーハンドリング戦略」 |
-| 09 | Adapter パターン | 395 | High | 5 言語の Adapter 比較 + Elixir コラム「I/O と外部システム」 |
-| 10 | Strategy パターン | 373 | High | 5 言語の Strategy 比較 + Elixir コラム「並行パターン」 |
-| 11 | Command パターン | 368 | Medium | 全 6 言語で統合、Elixir の簡潔な実装（148 行）を補足解説 |
-| 12 | Visitor パターン | 361 | Medium | 全 6 言語で統合、パターンマッチで Visitor が不要になるケースを解説 |
-| 13 | Abstract Factory パターン | 413 | High | Elixir が長い（604 行）ため、言語別ファクトリ表現の違いを詳述 |
-| 14 | Abstract Server パターン | 506 | High | Elixir が長い（729 行）ため、DIP の言語別実現方法を詳述 |
-**執筆順序**: 11 → 12 → 10 → 07 → 08 → 09 → 13 → 14
-**完了条件**:
-- [ ] 章 7-10 で Elixir コラムが独立セクションとして成立
-- [ ] 章 11-12 で Elixir の簡潔な実装に対する補足解説を含む
-- [ ] 章 13-14 で各言語の生成パターン表現を比較表にまとめる
-### イテレーション 4: ケーススタディ後半 + まとめ（Medium〜High 難易度）
-**対象**: 第 6 部 後半 2 章 + 第 7 部 全 3 章
-各言語の並行処理モデルが根本的に異なるため、章 18-19 が最難関です。
-| 章 | タイトル | 平均行数 | 難易度 | 統合方針 |
-|----|---------|---------|--------|---------|
-| 18 | 並行処理システム | 453 | High | 並行処理モデル（STM / OTP / Future / Async / Mutex）を言語別に深掘り |
-| 19 | Wa-Tor シミュレーション | 506 | High | 2D グリッドの不変表現と並行更新戦略を言語別に比較 |
-| 20 | パターン間の相互作用 | 380 | Medium | Composite+Decorator / Command+Observer の組み合わせを言語横断で比較 |
-| 21 | ベストプラクティス | 388 | Medium | 共通原則を抽出し、言語固有のイディオムを別セクションで整理 |
-| 22 | OO から FP への移行 | 457 | High | 言語のマルチパラダイム度合いに応じた移行戦略を言語別に詳述 |
-**執筆順序**: 20 → 21 → 18 → 19 → 22
-**完了条件**:
-- [ ] 章 18 で 6 言語の並行処理モデル比較表を含む
-- [ ] 章 19 で状態管理アプローチの違いを図解
-- [ ] 章 22 で言語別の移行難易度を評価
-### 全体スケジュール
-| イテレーション | 章数 | 難易度構成 | 主な課題 |
-|---------------|------|-----------|---------|
-| 1 | 3 章（01-03） | Low × 3 | なし（ウォームアップ） |
-| 2 | 6 章（04-06, 15-17） | Low × 3 + Medium × 3 | Clojure Spec・F# 拡張の分離 |
-| 3 | 8 章（07-14） | Medium × 2 + High × 6 | Elixir 独立カリキュラムの統合 |
-| 4 | 5 章（18-22） | Medium × 2 + High × 3 | 並行処理モデルの根本的差異 |
-### 進捗管理
-| 章 | タイトル | イテレーション | 難易度 | 状態 |
-|----|---------|---------------|--------|------|
-| 01 | 不変性とデータ変換 | 1 | Low | 完了 |
-| 02 | 関数合成と高階関数 | 1 | Low | 完了 |
-| 03 | 多態性の実現方法 | 1 | Low | 完了 |
-| 04 | データ検証 | 2 | Medium | 完了 |
-| 05 | プロパティベーステスト | 2 | Medium | 完了 |
-| 06 | TDD と関数型 | 2 | Medium | 完了 |
-| 07 | Composite パターン | 3 | High | 完了 |
-| 08 | Decorator パターン | 3 | High | 完了 |
-| 09 | Adapter パターン | 3 | High | 完了 |
-| 10 | Strategy パターン | 3 | High | 完了 |
-| 11 | Command パターン | 3 | Medium | 完了 |
-| 12 | Visitor パターン | 3 | Medium | 完了 |
-| 13 | Abstract Factory パターン | 3 | High | 完了 |
-| 14 | Abstract Server パターン | 3 | High | 完了 |
-| 15 | Gossiping Bus Drivers | 2 | Low | 完了 |
-| 16 | 給与計算システム | 2 | Low | 完了 |
-| 17 | レンタルビデオシステム | 2 | Low | 完了 |
-| 18 | 並行処理システム | 4 | High | 完了 |
-| 19 | Wa-Tor シミュレーション | 4 | High | 完了 |
-| 20 | パターン間の相互作用 | 4 | Medium | 完了 |
-| 21 | ベストプラクティス | 4 | Medium | 完了 |
-| 22 | OO から FP への移行 | 4 | High | 完了 |
-## 言語別個別記事へのリンク
-| 言語 | 個別記事一覧 |
-|------|-------------|
-| Clojure | [全 22 章](../clojure/index.md) |
-| Scala | [全 22 章](../scala/index.md) |
-| Elixir | [全 22 章](../elixir/index.md) |
-| F# | [全 22 章](../fsharp/index.md) |
-| Haskell | [全 22 章](../haskell/index.md) |
-| Rust | [全 22 章](../rust/index.md) |
-## 参照
-- 「Functional Design: Principles, Patterns, and Practices」Robert C. Martin
-- 「Clean Code」Robert C. Martin
-- [Clojure 公式ドキュメント](https://clojure.org/)
-- [Scala 公式ドキュメント](https://www.scala-lang.org/)
-- [Elixir 公式ドキュメント](https://elixir-lang.org/)
-- [F# 公式ドキュメント](https://fsharp.org/)
-- [Haskell 公式ドキュメント](https://www.haskell.org/)
-- [Rust 公式ドキュメント](https://www.rust-lang.org/)

package/lib/assets/docs/article/functional-desgin-ppp/clojure/01-immutability-and-data-transformation.md DELETED Viewed

@@ -1,282 +0,0 @@
----
-type: Article
-title: "第1章: 不変性とデータ変換"
-description: "関数型プログラミングの最も重要な概念の一つが不変性（Immutability）です。"
-tags: [article, functional-desgin-ppp, clojure]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-27T04:43:33Z }
----
-# 第1章: 不変性とデータ変換
-## はじめに
-関数型プログラミングの最も重要な概念の一つが**不変性（Immutability）**です。不変データ構造を使用することで、プログラムの予測可能性が向上し、並行処理でのバグを防ぎ、コードの理解と保守が容易になります。
-本章では、Clojure における不変データ構造の基本から、データ変換パイプライン、副作用の分離まで、実践的な例を通じて学びます。
-## 1. 不変データ構造の基本
-### なぜ不変性が重要なのか
-従来の命令型プログラミングでは、変数やオブジェクトの状態を直接変更します：
-```java
-// Java（可変）
-person.setAge(31);  // 元のオブジェクトが変更される
-```
-これに対し、Clojure のデータ構造は不変です。データを「変更」すると、新しいデータ構造が作成されます：
-```clojure
-(def original-person {:name "田中" :age 30})
-(defn update-age [person new-age]
-  (assoc person :age new-age))
-;; 使用例
-(def updated-person (update-age original-person 31))
-original-person   ;; => {:name "田中" :age 30}  ← 元のデータは変わらない
-updated-person    ;; => {:name "田中" :age 31}  ← 新しいデータ
-```
-### 不変性の利点
-1. **予測可能性**: データが変更されないため、関数の動作を予測しやすい
-2. **スレッドセーフ**: 複数のスレッドから安全にアクセスできる
-3. **履歴の保持**: 変更前のデータを保持できる（Undo/Redo の実装が容易）
-4. **デバッグの容易さ**: データの変更履歴を追跡しやすい
-## 2. 構造共有（Structural Sharing）
-「毎回新しいデータ構造を作成すると非効率では？」と思うかもしれません。Clojure は**構造共有**により、効率的にメモリを使用します。
-```clojure
-(def team {:name "開発チーム"
-           :members [{:name "田中" :role :developer}
-                     {:name "鈴木" :role :designer}
-                     {:name "佐藤" :role :manager}]})
-(defn add-member [team member]
-  (update team :members conj member))
-(def new-team (add-member team {:name "山田" :role :developer}))
-```
-`new-team` は新しいマップですが、`:name` の値や既存のメンバーデータは `team` と共有されています。変更されていない部分はコピーされず、参照が共有されます。
-```
-team:     {:name "開発チーム", :members [田中, 鈴木, 佐藤]}
-                ↓                    ↓
-new-team: {:name (共有), :members [田中, 鈴木, 佐藤, 山田]}
-                                  ↑ 既存データは共有
-```
-## 3. データ変換パイプライン
-関数型プログラミングでは、データを変換する一連の処理を**パイプライン**として表現します。Clojure では**スレッドマクロ**（`->` と `->>`）を使用して、読みやすいパイプラインを構築できます。
-### 実践例：注文処理システム
-```clojure
-(def order {:items [{:name "商品A" :price 1000 :quantity 2}
-                    {:name "商品B" :price 500 :quantity 3}
-                    {:name "商品C" :price 2000 :quantity 1}]
-            :customer {:name "山田" :membership :gold}})
-;; 各アイテムの小計を計算
-(defn calculate-subtotal [item]
-  (* (:price item) (:quantity item)))
-;; 会員種別に応じた割引率を取得
-(defn membership-discount [membership]
-  (case membership
-    :gold 0.1
-    :silver 0.05
-    :bronze 0.02
-    0))
-;; 注文の合計金額を計算
-(defn calculate-total [order]
-  (->> (:items order)
-       (map calculate-subtotal)
-       (reduce +)))
-;; 割引後の金額を計算
-(defn apply-discount [order total]
-  (let [discount-rate (-> order :customer :membership membership-discount)]
-    (* total (- 1 discount-rate))))
-```
-### スレッドマクロの使い分け
-- **`->`**（thread-first）: 結果を次の関数の**最初の引数**として渡す
-- **`->>`**（thread-last）: 結果を次の関数の**最後の引数**として渡す
-```clojure
-;; -> の例（マップの操作に便利）
-(-> order :customer :membership membership-discount)
-;; 展開: (membership-discount (:membership (:customer order)))
-;; ->> の例（コレクション操作に便利）
-(->> (:items order)
-     (map calculate-subtotal)
-     (reduce +))
-;; 展開: (reduce + (map calculate-subtotal (:items order)))
-```
-## 4. 副作用の分離
-関数型プログラミングでは、**純粋関数**と**副作用を持つ関数**を明確に分離することが重要です。
-### 純粋関数とは
-- 同じ入力に対して常に同じ出力を返す
-- 外部の状態を変更しない（副作用がない）
-```clojure
-;; 純粋関数
-(defn pure-calculate-tax [amount tax-rate]
-  (* amount tax-rate))
-;; 何度呼んでも同じ結果
-(pure-calculate-tax 1000 0.1)  ;; => 100.0
-(pure-calculate-tax 1000 0.1)  ;; => 100.0
-```
-### 副作用の分離パターン
-ビジネスロジック（純粋関数）と副作用（I/O）を分離します：
-```clojure
-;; ビジネスロジック（純粋関数）
-(defn calculate-invoice [items tax-rate]
-  (let [subtotal (reduce + (map calculate-subtotal items))
-        tax (pure-calculate-tax subtotal tax-rate)
-        total (+ subtotal tax)]
-    {:subtotal subtotal
-     :tax tax
-     :total total}))
-;; 副作用を含む処理（分離）
-(defn save-invoice! [invoice]
-  ;; データベースへの保存（副作用）
-  (println "Saving invoice:" invoice)
-  invoice)
-(defn send-notification! [invoice customer-email]
-  ;; メール送信（副作用）
-  (println "Sending notification to:" customer-email)
-  invoice)
-;; 処理全体のオーケストレーション
-(defn process-and-save-invoice! [items tax-rate customer-email]
-  (-> (calculate-invoice items tax-rate)
-      save-invoice!
-      (send-notification! customer-email)))
-```
-副作用を持つ関数には `!` サフィックスを付ける慣例があります。
-## 5. 永続的データ構造の活用：Undo/Redo の実装
-不変データ構造を活用すると、履歴管理が非常に簡単に実装できます。
-```clojure
-;; 履歴を保持するデータ構造
-(defn create-history []
-  {:current nil
-   :past []
-   :future []})
-(defn push-state [history new-state]
-  (-> history
-      (update :past conj (:current history))
-      (assoc :current new-state)
-      (assoc :future [])))
-(defn undo [history]
-  (if (empty? (:past history))
-    history
-    (let [previous (peek (:past history))]
-      (-> history
-          (update :future conj (:current history))
-          (assoc :current previous)
-          (update :past pop)))))
-(defn redo [history]
-  (if (empty? (:future history))
-    history
-    (let [next-state (peek (:future history))]
-      (-> history
-          (update :past conj (:current history))
-          (assoc :current next-state)
-          (update :future pop)))))
-```
-### 使用例
-```clojure
-(def history
-  (-> (create-history)
-      (push-state {:text "Hello"})
-      (push-state {:text "Hello World"})
-      (push-state {:text "Hello World!"})))
-(:current history)  ;; => {:text "Hello World!"}
-(def after-undo (undo history))
-(:current after-undo)  ;; => {:text "Hello World"}
-(def after-redo (redo after-undo))
-(:current after-redo)  ;; => {:text "Hello World!"}
-```
-## 6. トランスデューサーによる効率的な変換
-複数の変換を行う場合、通常は中間コレクションが作成されます。**トランスデューサー**を使用すると、複数の変換を1回のパスで処理できます。
-```clojure
-;; 複数の変換を合成
-(def xf-process-items
-  (comp
-   (filter #(> (:quantity %) 0))           ;; 数量が0より大きいものをフィルタ
-   (map #(assoc % :subtotal (calculate-subtotal %)))  ;; 小計を追加
-   (filter #(> (:subtotal %) 100))))       ;; 小計が100より大きいものをフィルタ
-;; トランスデューサーを使用した効率的な処理
-(defn process-items-efficiently [items]
-  (into [] xf-process-items items))
-```
-トランスデューサーの利点：
-- 中間コレクションを作成しない
-- 遅延評価との組み合わせが可能
-- 様々なコンテキスト（ベクター、チャネルなど）で再利用可能
-## まとめ
-本章では、関数型プログラミングの基礎である不変性について学びました：
-1. **不変データ構造**: データは変更されず、新しいデータが作成される
-2. **構造共有**: 効率的なメモリ使用を実現
-3. **データ変換パイプライン**: スレッドマクロによる読みやすい変換処理
-4. **副作用の分離**: 純粋関数とI/O処理の明確な分離
-5. **履歴管理**: 不変性を活用したUndo/Redoの簡潔な実装
-6. **トランスデューサー**: 効率的な複合変換
-これらの概念は、関数型プログラミングの他のすべてのパターンの基盤となります。
-## 参考コード
-本章のコード例は以下のファイルで確認できます：
-- ソースコード: `apps/clojure/part1/src/immutability.clj`
-- テストコード: `apps/clojure/part1/spec/immutability_spec.clj`
-## 次章予告
-次章では、**関数合成と高階関数**について学びます。小さな関数を組み合わせて複雑な処理を構築する方法を探ります。