Merge branch 'develop'

Author: BreadMotion

WebSite/content/blog/blog_00030.md

@@ -17,7 +17,7 @@ thumbnail: assets/img/ogp.png
 
 プロトタイプパターンは既存のオブジェクトを複製して新しいインスタンスを作ることでオブジェクト生成を行う生成パターンです。  
 
-一次情報として Wikipedia の定義を引用します。
+一次情報として Wikipedia の定義を引用します。  
 
 > "ソフトウェア工学において、プロトタイプパターンは、新しいオブジェクトをプロトタイプとなるインスタンスを複製することで生成する生成型デザインパターンである。"  
 > （出典: [https://en.wikipedia.org/wiki/Prototype_pattern](https://en.wikipedia.org/wiki/Prototype_pattern)）

WebSite/content/other/blog_00031.md

@@ -2,7 +2,7 @@
 title: GoFデザインパターン - 抽象ファクトリ編
 date: 2026-02-03
 category: Coding
-description: GoFコレクションにおける抽象ファクトリパターン実践ガイド：概念、使いどころ、C++/Pythonの実装例、注意点と出典を実用的に解説します
+description: GoFコレクションにおける抽象ファクトリパターン実践ガイド：概念、使いどころ、C++の実装例、注意点と出典を実用的に解説します
 tags: [Coding, DesignPattern]
 recommended: true
 thumbnail: assets/img/ogp.png
@@ -13,7 +13,7 @@ thumbnail: assets/img/ogp.png
 今回は GoF（Gang of Four）のデザインパターンの抽象ファクトリ編になります。  
 サンプルコード（C++）、作り方、使うタイミング、注意点などを含めて実用的に解説します。 
 
-## 抽象ファクトリとは
+## はじめに
 
 抽象ファクトリとは 関連する、あるいは依存する　オブジェクト群を　具体クラスを明示せずに生成するインターフェースを提供するパターンです。  
 
@@ -42,7 +42,7 @@ thumbnail: assets/img/ogp.png
 - 単一製品の切り替えなら `Factory Method` の方が適切な場合がある
 - 依存注入（DI）と組み合わせるとテスト性が向上する
 
-## 構成要素
+## 構造（要素）
 
 - `AbstractFactory`（抽象ファクトリ）: 製品群を生成するファクトリのインターフェース
 - `ConcreteFactory`（具象ファクトリ）: 抽象ファクトリを実装し、関連する具象製品を生成

WebSite/content/other/blog_00032.md

@@ -0,0 +1,140 @@
+---
+title: GoFデザインパターン - ビルダー編
+date: 2026-02-04
+category: Coding
+description: GoFコレクションにおけるビルダーパターン実践ガイド：概念、使いどころ、C++の実装例、注意点と出典を実用的に解説します
+tags: [Coding, DesignPattern]
+recommended: true
+thumbnail: assets/img/ogp.png
+---
+
+こんにちは！パン君です。
+
+今回は GoF（Gang of Four）のデザインパターンのビルダー編になります。  
+サンプルコード（C++）、作り方、使うタイミング、注意点などを含めて実用的に解説します。
+
+# はじめに
+
+ビルドパターンは複雑なオブジェクトの生成過程を分離して可読性・拡張性を高めることができます。  
+
+一次情報として Wikipedia の定義を引用します。  
+
+> "ビルダー設計パターンの目的は、複雑なオブジェクトの構築とその表現を分離することである。これにより、同じ構築プロセスで異なる表現を生成できる。"  
+> （出典: [https://en.wikipedia.org/wiki/Builder_pattern](https://en.wikipedia.org/wiki/Builder_pattern)）  
+
+[!CARD](https://en.wikipedia.org/wiki/Builder_pattern)
+
+## 構造（要素）
+
+典型的な構成は次の通りです。
+
+- `Product`：最終的に生成される複雑なオブジェクト
+- `Builder` : `buildPartX()` のようなステップを定義し、`getResult()` を持つ
+- `ConcreteBuilder`：`Builder` を実装し、内部に可変な部品を持ち最終的な `Product` を返す
+- `Director`：構築の手順 を持ち、`Builder` に構築命令を出す。小さなケースでは Director を省くことも多い
+
+## C++ 実装例
+
+以下は最小限の C++ 例です。`Director` を使ったパターンの典型例です。
+
+```cpp
+// Product.h  -- 生成対象
+#pragma once
+#include <string>
+
+struct Product {
+    std::string partA;
+    std::string partB;
+    std::string partC;
+};
+
+// Builder.h -- 抽象ビルダー
+#pragma once
+#include <memory>
+class Builder {
+public:
+    virtual ~Builder() = default;
+    virtual void BuildPartA() = 0;
+    virtual void BuildPartB() = 0;
+    virtual void BuildPartC() = 0;
+    virtual std::unique_ptr<Product> GetResult() = 0;
+};
+
+// ConcreteBuilder.h
+#pragma once
+#include "Builder.h"
+#include "Product.h"
+#include <memory>
+
+class ConcreteBuilder : public Builder {
+private:
+    std::unique_ptr<Product> product_;
+public:
+    ConcreteBuilder() : product_(std::make_unique<Product>()) {}
+    void BuildPartA() override { product_->partA = "Engine"; }
+    void BuildPartB() override { product_->partB = "Wheels"; }
+    void BuildPartC() override { product_->partC = "Body"; }
+    std::unique_ptr<Product> GetResult() override {
+        return std::move(product_);
+    }
+};
+
+// Director.h
+#pragma once
+#include "Builder.h"
+
+class Director {
+public:
+    void ConstructSportsCar(Builder& builder) {
+        builder.BuildPartA();
+        builder.BuildPartB();
+        builder.BuildPartC();
+    }
+    void ConstructToyCar(Builder& builder) {
+        builder.BuildPartB();
+        // Toy car doesn't need engine
+    }
+};
+
+// main.cpp
+#include <iostream>
+int main() {
+    ConcreteBuilder builder;
+    Director director;
+    director.ConstructSportsCar(builder);
+    auto product = builder.GetResult();
+    std::cout << "Product parts: " << product->partA << ", " << product->partB << ", " << product->partC << "\n";
+}
+```
+
+この実装のポイントは 構築手順 と 具体的構築 が分離されていることです。  
+ConcreteBuilder を差し替えるだけで多様性の実現が図れます。  
+
+## いつ使うか
+
+**ビルダーを検討する代表ケース**
+- コンストラクタのパラメータが多く、ほとんどがオプションである場合（名前付き引数やファクトリでも代替可）
+- 段階的または複雑な初期化が必要で、処理手順を分離したい場合（テスト用に段階的に検証できる）
+- 同じ構築手順で異なる表現（複数の `ConcreteBuilder`）を生成したい場合
+- 不変オブジェクト（immutable）の生成を読みやすくしたい場合（Builder が可変の中間表現を組み立て最終生成で不変オブジェクトを返す）
+
+**代替手段**
+- 言語がサポートする named / optional parameters（簡潔なケース）
+- `Factory Method` / `Abstract Factory`（生成の責務をサブクラスやグループで管理したい場合）
+- コンストラクタの段階的補助関数（簡単なケースで十分なことが多い）
+
+## まとめ
+
+Builder は 構築手順と表現の分離 を目的とした強力なパターンで、複雑な初期化・可変な表現を扱う場面で有効です。
+しかし Builder はミュータブル性や DI との相性、テスト設計など考慮すべきトレードオフがあります。  
+導入前に影響範囲（生成元・シリアライズ・テスト）をした方がいいです。  
+
+参考・出典を記します   
+
+[!CARD](https://en.wikipedia.org/wiki/Builder_pattern)  
+
+それでは、次回は別の GoF パターンについても解説していきます。 
+この記事で提示したコードは学習目的に簡潔化しています。  
+実プロダクションで採用する際は要件に合わせて十分に検討してください  
+
+以上、パン君でした！