Factory Methodパターン調査ドキュメント

調査概要

• 調査目的: 「Mooで覚えるオブジェクト指向プログラミング」シリーズを読了した読者が、Factory Methodパターンを学べる教材作成のための基礎資料
• 調査実施日: 2026年1月9日
• 技術スタック: Perl v5.36以降 / Moo
• 想定読者: オブジェクト指向の基礎（クラス、継承）が理解できている読者
• 難易度評価: 3/5（インターフェースや継承、抽象クラスの理解が必要）
• 前提知識: 「Mooで覚えるオブジェクト指向プログラミング」シリーズ（全12回）を読了済み

1. Factory Methodパターンの基礎

1.1 定義と目的

要点:

• Factory Methodパターンは、GoF（Gang of Four）の**生成パターン（Creational Patterns）**の1つ
• 「オブジェクトを生成するためのインターフェースを定義し、どのクラスをインスタンス化するかはサブクラスに決定させる」
• クラスのインスタンス化をサブクラスに遅延させることで、クライアントコードを具体的なクラスから分離する
• 継承を使って「どのオブジェクトを作るか」をサブクラスに委ねる

根拠:

• GoF書籍「Design Patterns: Elements of Reusable Object-Oriented Software」（1994年）で定義
• Refactoring Guru、GeeksforGeeks、Wikipedia等の主要技術サイトで一致した説明

仮定:

• 読者は「Mooで覚えるオブジェクト指向プログラミング」シリーズで継承（extends）を学んでいる
• 「Mooを使ってディスパッチャーを作ってみよう」シリーズでStrategy パターンを学んでいる可能性が高い

出典:

• Wikipedia: Factory method pattern - https://en.wikipedia.org/wiki/Factory_method_pattern
• Refactoring Guru: Factory Method - https://refactoring.guru/design-patterns/factory-method
• GeeksforGeeks: Factory method Design Pattern - https://www.geeksforgeeks.org/system-design/factory-method-for-designing-pattern/
• Baeldung: Factory Method vs. Factory vs. Abstract Factory - https://www.baeldung.com/cs/factory-method-vs-factory-vs-abstract-factory

信頼度: 9/10（GoF原典および複数の信頼できる技術サイト）

1.2 GoFパターンにおける位置づけ

要点:

Factory Methodは、GoFの23パターンのうち生成パターン（Creational Patterns）5種類の1つです。

根拠:

• GoFの分類体系で明確に定義されている
• 生成パターンはオブジェクトの生成メカニズムに関するパターン

出典:

• 内部warehouse: /content/warehouse/design-patterns-overview.md
• GeeksforGeeks: Creational Design Patterns - https://www.geeksforgeeks.org/system-design/creational-design-pattern/

信頼度: 9/10

1.3 他の生成パターンとの違い

Simple Factory との違い（注意: これはGoFパターンではない）

コード例（Simple Factory）:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Simple Factory - if/elseで分岐
package SimpleShapeFactory;
use strict;
use warnings;

sub create_shape {
    my ($class, $type) = @_;
    if ($type eq 'circle') {
        require Circle;
        return Circle->new();
    }
    elsif ($type eq 'square') {
        require Square;
        return Square->new();
    }
    else {
        die "Unknown shape type: $type";
    }
}
1;

根拠:

• Simple Factoryはif/else/switchを使用するため、新製品追加時にファクトリクラスの修正が必要（OCP違反）
• Factory Methodは新しいCreatorサブクラスを追加することで拡張可能（OCP準拠）

出典:

• Stack Overflow: Design Patterns: Factory vs Factory method vs Abstract Factory - https://stackoverflow.com/questions/13029261/design-patterns-factory-vs-factory-method-vs-abstract-factory
• Dev.to: Factory Method vs Abstract Factory - https://dev.to/buildwithhicham/factory-method-vs-abstract-factory-whats-the-difference-glb

信頼度: 9/10

Abstract Factory との違い

根拠:

• Factory Methodは単一製品の生成にフォーカス
• Abstract Factoryは関連する製品群（ファミリー）の一貫した生成にフォーカス

出典:

• GeeksforGeeks: Differences Between Abstract Factory and Factory Design Patterns - https://www.geeksforgeeks.org/system-design/differences-between-abstract-factory-and-factory-design-patterns/
• C# Corner: Factory Pattern vs Abstract Factory Pattern - https://www.c-sharpcorner.com/blogs/factory-pattern-vs-abstract-factory-pattern

信頼度: 9/10

Builder との違い

信頼度: 9/10

Prototype との違い

信頼度: 9/10

2. Factory Methodパターンの構造

2.1 UML図

	classDiagram
    class Creator {
        <<abstract>>
        +factoryMethod() Product
        +someOperation()
    }
    class ConcreteCreatorA {
        +factoryMethod() Product
    }
    class ConcreteCreatorB {
        +factoryMethod() Product
    }
    class Product {
        <<interface>>
        +doStuff()
    }
    class ConcreteProductA {
        +doStuff()
    }
    class ConcreteProductB {
        +doStuff()
    }
    
    Creator <|-- ConcreteCreatorA
    Creator <|-- ConcreteCreatorB
    Product <|.. ConcreteProductA
    Product <|.. ConcreteProductB
    ConcreteCreatorA ..> ConcreteProductA : creates
    ConcreteCreatorB ..> ConcreteProductB : creates
    Creator --> Product : uses

テキスト版UML:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    +-------------------+                    +-------------------+
    |   <<abstract>>    |                    |   <<interface>>   |
    |     Creator       |                    |      Product      |
    +-------------------+                    +-------------------+
    | +factoryMethod()  |----uses--->        | +doStuff()        |
    | +someOperation()  |                    +-------------------+
    +-------------------+                            ^
            ^                                        |
            |                               +--------+--------+
    +-------+-------+                       |                 |
    |               |                +-------------+   +-------------+
+-------------------+  +-------------------+  | ConcreteProductA |   | ConcreteProductB |
| ConcreteCreatorA  |  | ConcreteCreatorB  |  +------------------+   +------------------+
+-------------------+  +-------------------+  | +doStuff()       |   | +doStuff()       |
| +factoryMethod()  |  | +factoryMethod()  |  +------------------+   +------------------+
+-------------------+  +-------------------+
        |                      |
        |                      |
   creates                creates
        |                      |
        v                      v
+------------------+   +------------------+
| ConcreteProductA |   | ConcreteProductB |
+------------------+   +------------------+

信頼度: 9/10

2.2 構成要素の説明

要点:

• Creatorはファクトリメソッド（factoryMethod）を宣言し、サブクラスが実装
• Creatorは製品を「使う」ビジネスロジック（someOperation）も持つことができる
• ConcreteCreatorは具体的な製品クラスのインスタンスを返す
• クライアントはCreator経由で製品を取得し、Productインターフェースで操作

根拠:

• GoF原典の構造定義
• UMLBoard、Visual Paradigm等のUML解説サイト

出典:

• UMLBoard: The Factory Method Design Pattern - https://www.umlboard.com/design-patterns/factory-method.html
• System Overflow: What is the Factory Method Pattern? - https://www.systemoverflow.com/learn/creational-patterns/factory-method-pattern/what-is-the-factory-method-pattern

信頼度: 9/10

3. メリット・デメリット

3.1 メリット

根拠:

• SOLID原則（特にOCP、SRP、DIP）との親和性
• 実務での拡張性・保守性の向上

出典:

• GeeksforGeeks: Factory method Design Pattern - https://www.geeksforgeeks.org/system-design/factory-method-for-designing-pattern/
• The Morning Dev: Factory Method Pattern Explained - https://themorningdev.com/factory-method-pattern/
• Software Pattern Lexicon: Factory Method Pattern - https://softwarepatternslexicon.com/mastering-design-patterns/creational-design-patterns/factory-method-pattern/

信頼度: 9/10

3.2 デメリット

根拠:

• 過剰設計（オーバーエンジニアリング）のリスク
• 実務での経験則

出典:

• GeeksforGeeks: Factory method Design Pattern - https://www.geeksforgeeks.org/system-design/factory-method-for-designing-pattern/
• Software Pattern Lexicon: Factory Method Pattern - https://softwarepatternslexicon.com/mastering-design-patterns/creational-design-patterns/factory-method-pattern/

信頼度: 9/10

3.3 いつ使うべきか

適用すべき場面:

1. クラスが生成すべきオブジェクトのクラスを事前に知らない場合

   • 実行時やユーザー入力に基づいて生成するクラスが決まる

2. サブクラスに生成すべきオブジェクトを指定させたい場合

   • フレームワークが骨格を提供し、ユーザーがカスタマイズ

3. オブジェクト生成ロジックを局所化・カプセル化したい場合

   • 生成ロジックの変更がシステム全体に影響しない

4. Open/Closed原則に従いたい場合

   • 既存コードを修正せずに新しい製品タイプを追加

5. プラグインアーキテクチャを構築したい場合

   • プラグインが自身の製品を提供

根拠:

• GoF原典での適用条件
• 実務でのユースケース

出典:

• GeeksforGeeks: Factory method Design Pattern - https://www.geeksforgeeks.org/system-design/factory-method-for-designing-pattern/
• Software Pattern Lexicon: Factory Method Pattern - https://softwarepatternslexicon.com/mastering-design-patterns/creational-design-patterns/factory-method-pattern/

信頼度: 9/10

3.4 いつ使うべきでないか

適用すべきでない場面:

1. 製品タイプが1〜2個で、今後も増えない見込みの場合

   • Simple Factoryまたは直接インスタンス化で十分

2. オブジェクト生成がシンプルで、複雑なロジックが不要な場合

   • パターン適用によるオーバーヘッドがメリットを上回る

3. 継承を避けたい設計方針の場合

   • 合成ベースのパターン（Abstract Factory、依存性注入）を検討

4. 動的に製品タイプを追加する必要がない場合

   • 静的なファクトリメソッドで十分

信頼度: 9/10

3.5 アンチパターンへの注意点

信頼度: 7/10

4. 実装例

4.1 Perl/Moo での実装例

Product Role（製品インターフェース）

1
2
3
4
5
6
7
8
9

# Document.pm
package Document;
use Moo::Role;
use v5.36;

requires 'render';
requires 'get_extension';

1;

Concrete Products（具象製品）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

# PdfDocument.pm
package PdfDocument;
use Moo;
use v5.36;
with 'Document';

sub render ($self) {
    say "PDF形式でドキュメントをレンダリングします";
}

sub get_extension ($self) {
    return '.pdf';
}

1;

# WordDocument.pm
package WordDocument;
use Moo;
use v5.36;
with 'Document';

sub render ($self) {
    say "Word形式でドキュメントをレンダリングします";
}

sub get_extension ($self) {
    return '.docx';
}

1;

# HtmlDocument.pm
package HtmlDocument;
use Moo;
use v5.36;
with 'Document';

sub render ($self) {
    say "HTML形式でドキュメントをレンダリングします";
}

sub get_extension ($self) {
    return '.html';
}

1;

Creator（抽象作成者）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# DocumentCreator.pm
package DocumentCreator;
use Moo;
use v5.36;

# Factory Method - サブクラスで実装
sub create_document ($self) {
    die "create_document() must be implemented by subclass";
}

# ビジネスロジック - 製品を使用する
sub generate_report ($self, $title) {
    my $doc = $self->create_document();
    say "レポート '$title' を" . $doc->get_extension() . "形式で生成中...";
    $doc->render();
    return $doc;
}

1;

Concrete Creators（具象作成者）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# PdfCreator.pm
package PdfCreator;
use Moo;
use v5.36;
extends 'DocumentCreator';
use PdfDocument;

sub create_document ($self) {
    return PdfDocument->new();
}

1;

# WordCreator.pm
package WordCreator;
use Moo;
use v5.36;
extends 'DocumentCreator';
use WordDocument;

sub create_document ($self) {
    return WordDocument->new();
}

1;

# HtmlCreator.pm
package HtmlCreator;
use Moo;
use v5.36;
extends 'DocumentCreator';
use HtmlDocument;

sub create_document ($self) {
    return HtmlDocument->new();
}

1;

使用例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# main.pl
use v5.36;
use PdfCreator;
use WordCreator;
use HtmlCreator;

# PDF形式でレポート生成
my $pdf_creator = PdfCreator->new();
$pdf_creator->generate_report("売上レポート");
# 出力:
# レポート '売上レポート' を.pdf形式で生成中...
# PDF形式でドキュメントをレンダリングします

# Word形式でレポート生成
my $word_creator = WordCreator->new();
$word_creator->generate_report("月次報告書");
# 出力:
# レポート '月次報告書' を.docx形式で生成中...
# Word形式でドキュメントをレンダリングします

# HTML形式でレポート生成
my $html_creator = HtmlCreator->new();
$html_creator->generate_report("Webレポート");
# 出力:
# レポート 'Webレポート' を.html形式で生成中...
# HTML形式でドキュメントをレンダリングします

根拠:

• Moo::Roleのrequiresでインターフェースを定義
• extendsで継承を実現
• v5.36のシグネチャでモダンPerlの記法

出典:

• MetaCPAN: Moo - https://metacpan.org/pod/Moo
• MetaCPAN: Moo::Role - https://metacpan.org/pod/Moo::Role
• The Weekly Challenge: Design Pattern Factory - https://theweeklychallenge.org/blog/design-pattern-factory/
• Perl Maven: OOP with Moo - https://perlmaven.com/oop-with-moo

信頼度: 9/10

4.2 他言語との比較

Java での実装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// Product interface
interface Document {
    void render();
    String getExtension();
}

// Concrete Product
class PdfDocument implements Document {
    public void render() {
        System.out.println("PDF形式でレンダリング");
    }
    public String getExtension() { return ".pdf"; }
}

// Creator (abstract class)
abstract class DocumentCreator {
    // Factory Method
    public abstract Document createDocument();
    
    // Business logic
    public void generateReport(String title) {
        Document doc = createDocument();
        System.out.println("レポート '" + title + "' を生成中...");
        doc.render();
    }
}

// Concrete Creator
class PdfCreator extends DocumentCreator {
    @Override
    public Document createDocument() {
        return new PdfDocument();
    }
}

Python での実装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

from abc import ABC, abstractmethod

# Product interface
class Document(ABC):
    @abstractmethod
    def render(self) -> None:
        pass
    
    @abstractmethod
    def get_extension(self) -> str:
        pass

# Concrete Product
class PdfDocument(Document):
    def render(self) -> None:
        print("PDF形式でレンダリング")
    
    def get_extension(self) -> str:
        return ".pdf"

# Creator (abstract class)
class DocumentCreator(ABC):
    @abstractmethod
    def create_document(self) -> Document:
        pass
    
    def generate_report(self, title: str) -> None:
        doc = self.create_document()
        print(f"レポート '{title}' を生成中...")
        doc.render()

# Concrete Creator
class PdfCreator(DocumentCreator):
    def create_document(self) -> Document:
        return PdfDocument()

TypeScript での実装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// Product interface
interface Document {
    render(): void;
    getExtension(): string;
}

// Concrete Product
class PdfDocument implements Document {
    render(): void {
        console.log("PDF形式でレンダリング");
    }
    getExtension(): string {
        return ".pdf";
    }
}

// Creator (abstract class)
abstract class DocumentCreator {
    abstract createDocument(): Document;
    
    generateReport(title: string): void {
        const doc = this.createDocument();
        console.log(`レポート '${title}' を生成中...`);
        doc.render();
    }
}

// Concrete Creator
class PdfCreator extends DocumentCreator {
    createDocument(): Document {
        return new PdfDocument();
    }
}

言語間比較表

信頼度: 9/10

5. 実世界での活用例

5.1 フレームワークでの活用

Spring Framework（Java）

要点:

• Spring DIコンテナは内部的にFactory Methodパターンを活用
• factory-method属性でBean生成をカスタマイズ可能
• BeanFactoryがFactory Methodの代表例

出典:

• Baeldung: Creating Spring Beans Through Factory Methods - https://www.baeldung.com/spring-beans-factory-methods
• GeeksforGeeks: Spring Dependency Injection with Factory Method - https://www.geeksforgeeks.org/springboot/spring-dependency-injection-with-factory-method/

信頼度: 9/10

Ruby on Rails

要点:

• ActiveRecordの接続アダプターはFactory Method的な構造
• 接続管理が抽象化され、DBドライバに応じた具象クラスを返す

信頼度: 7/10

5.2 ドキュメント生成システム

要点:

• PDF、Word、Text、HTML等の複数形式に対応
• ユーザー入力や設定に基づいて適切なDocument生成器を選択
• 新しい形式の追加が容易

典型的な実装:

1. DocumentCreatorが抽象ファクトリメソッドcreateDocument()を宣言
2. PdfCreator、WordCreator等がそれぞれの形式を生成
3. クライアントはDocumentCreator経由で製品を取得

出典:

• GitHub: fullstacksmith/Design-Patterns - https://github.com/fullstacksmith/Design-Patterns

信頼度: 9/10

5.3 ログシステム

要点:

• ConsoleLogger、FileLogger、DatabaseLogger等を切り替え
• 実行環境や設定に応じてロガーを選択
• 新しいロギング先の追加が容易

出典:

• Software Pattern Lexicon: Factory Method Pattern Use Cases - https://softwarepatternslexicon.com/java/creational-patterns/factory-method-pattern/use-cases-and-examples/

信頼度: 9/10

5.4 通知システム

要点:

• Email、SMS、Push通知、Slack等の複数チャネル対応
• 設定やユーザー設定に応じて通知方法を選択
• 新しい通知チャネルの追加が容易

出典:

• AlgoMaster.io: Factory Method - https://algomaster.io/learn/lld/factory-method
• Java Guides: Java Factory Pattern with Real-World Examples - https://www.javaguides.net/2025/06/java-factory-pattern-with-real-world-examples.html

信頼度: 9/10

5.5 GUI要素の生成

要点:

• ボタン、ダイアログ、入力フォーム等のUI要素
• OSやテーマに応じた外観のカスタマイズ
• クロスプラットフォーム対応

典型例:

• WindowsButtonCreator、MacButtonCreator
• Material UIボタン、iOS風ボタン

信頼度: 7/10

6. 関連パターン

6.1 Template Methodパターンとの関係

要点:

• Factory MethodはTemplate Methodの特殊化と見なすことができる
• Template Methodは「アルゴリズムの骨格を定義し、一部のステップをサブクラスに委ねる」
• Factory Methodは「オブジェクト生成」という特定のステップをサブクラスに委ねる

根拠:

• GoF書籍での定義
• 両パターンとも継承を活用してカスタマイズポイントを提供

出典:

• Stack Exchange: “Factory Method is a specialization of Template Method” - https://softwareengineering.stackexchange.com/questions/340099/factory-method-is-a-specialization-of-template-method-how
• Baeldung: Factory Method vs. Factory vs. Abstract Factory - https://www.baeldung.com/cs/factory-method-vs-factory-vs-abstract-factory

信頼度: 9/10

6.2 Abstract Factoryパターンとの違い（再掲・詳細）

要点:

• Factory Methodは1つの製品の生成にフォーカス
• Abstract Factoryは**関連する製品群（ファミリー）**の生成にフォーカス
• Factory Methodは継承ベース、Abstract Factoryは合成ベース
• Abstract FactoryはFactory Methodを内部的に使用することが多い

関係図:

	flowchart LR
    A[Abstract Factory] -->|内部で使用| B[Factory Method]
    B -->|単一製品の生成| C[Product]
    A -->|製品群の生成| D[Product Family]

出典:

• Software Pattern Lexicon: Abstract Factory vs Factory Method - https://softwarepatternslexicon.com/java/creational-patterns/abstract-factory-pattern/abstract-factory-vs-factory-method/

信頼度: 9/10

6.3 Simple Factory（Static Factory）との違い（再掲・詳細）

要点:

• Simple FactoryはGoFパターンではない（プログラミングイディオム）
• 単一のメソッド内でif/else/switchを使って製品を選択
• 新製品追加時にファクトリクラスの修正が必要（OCP違反）
• シンプルで理解しやすいが、拡張性に欠ける

使い分け指針:

信頼度: 9/10

7. 競合記事の分析

7.1 日本語の主要記事

7.2 差別化ポイントの抽出

既存記事の問題点:

1. Perl/Moo特化の記事が少ない: 日本語でPerl向けのFactory Method解説は希少
2. 抽象的な例が多い: 動物、図形など、実践性の低い例
3. 前提知識の説明不足: いきなりパターンの説明から始まる
4. 他の生成パターンとの違いが曖昧: 読者が使い分けに困る

本教材シリーズの強み:

1. 前シリーズとの継続性: 「Mooで覚えるオブジェクト指向プログラミング」で学んだ概念を活用
2. Strategyパターンとの対比: 「Mooを使ってディスパッチャーを作ってみよう」で学んだパターンとの違いを明確化
3. 段階的な難易度: 1記事1概念、コード例2つまでの制約
4. Perl/Moo特化: v5.36対応のモダンPerl記法
5. 生成パターンの体系的理解: 他の生成パターンとの違いを明確に

信頼度: 9/10

8. 内部リンク候補の調査

8.1 「Mooで覚えるオブジェクト指向プログラミング」シリーズ（全12回）

本シリーズ記事の前提知識となる既存記事。

特に重要な関連:

• 第8回（継承）: Factory Methodは継承を中心に据えたパターン
• 第10回（Moo::Role）: Product インターフェースをRoleで定義する際に必須

8.2 「Mooを使ってディスパッチャーを作ってみよう」シリーズ（全12回）

Strategy パターンを扱うシリーズ：Factory Methodとの違いを理解する上で参考になる。

8.3 デザインパターン関連

8.4 Moo/オブジェクト指向関連

9. 既存シリーズとの重複チェック

9.1 「Mooで覚えるオブジェクト指向プログラミング」シリーズ

重複なし: このシリーズはOOPの基礎（クラス、継承、ロール等）を扱い、デザインパターンは直接扱っていない。Factory Methodシリーズの前提知識として位置づけられる。

9.2 「Mooを使ってディスパッチャーを作ってみよう」シリーズ

重複なし: このシリーズはStrategy パターン（振る舞いパターン）を扱う。Factory Methodは生成パターンであり、異なるアプローチ。

差別化ポイント:

9.3 「Mooを使ってデータエクスポーターを作ってみよう」シリーズ（Strategyパターン）

確認必要: Strategy パターンを別題材で扱うシリーズがある場合、Factory Methodシリーズとは明確に差別化される。

9.4 結論

Factory Methodパターンは生成パターンであり、既存シリーズで扱うStrategy パターン（振る舞いパターン）とは異なるカテゴリ。重複なく、新しいシリーズとして展開可能。

10. 参考文献・リソースリスト

10.1 必読リソース

書籍

Webリソース

11. 調査結果のサマリー

11.1 主要な発見

1. Factory Methodの位置づけ: GoFの生成パターンの1つ。継承を活用してオブジェクト生成をサブクラスに委譲する

2. Simple Factoryとの違い: Simple Factoryはif/elseで製品を選択（GoFパターンではない）。Factory Methodはサブクラス化で拡張（OCP準拠）

3. Abstract Factoryとの違い: Factory Methodは単一製品、Abstract Factoryは製品群（ファミリー）を扱う

4. Template Methodとの関係: Factory MethodはTemplate Methodの特殊化（生成に特化したTemplate Method）

5. Perl/Moo実装の容易さ: Moo::RoleのrequiresでProductインターフェースを定義し、extendsでCreator継承、各ConcreteCreatorがファクトリメソッドをオーバーライド

6. 既存シリーズとの連携: 「Mooで覚えるオブジェクト指向プログラミング」第8回（継承）、第10回（Moo::Role）が直接的な前提知識

調査完了日: 2026年1月9日 調査者: 調査・情報収集エージェント