Factory Methodパターンとは？C#で学ぶオブジェクト生成の基本構造 Part1

受講者数No.1！初心者からプロへ導く信頼のスクール

短期間で習得可能！未経験から実践力を磨く充実のプログラム

今なら無料相談でAmazonギフトカードがもらえる！

はじめに：直接newするコードがなぜ問題になるのか

C#で開発していると、ついこう書いてしまうことがあります。

if (type == "PDF")
    report = new PdfReport();
else if (type == "Excel")
    report = new ExcelReport();

動きはしますが、少しずつ条件が増えると大変なことになります。
「新しいレポート形式を追加したい」となるたびに
このコードを修正しなければならない──。

このような構造は“変更に弱い”コードと呼ばれます。
プロジェクトが成長するほど、if 文や new が増え、
やがてバグの温床になります。

そんな「生成の混乱」を解消するのが、Factory Methodパターンです。

Factory Methodパターンとは何か

Factory Methodパターンとは、

「どのクラスを生成するかをサブクラスに任せる」
設計パターンです。

もう少し簡単に言えば、
「オブジェクトを作る責任を、使う側ではなく“専門の工場”に分ける」仕組みです。

💬 日常の例で考えてみましょう

例えば、あなたが“車”を必要としているとします。
あなたは車を「作る」より「使う」ことに集中したいはず。
実際の製造（トヨタ・ホンダ・スズキ）はそれぞれが担当します。

同じように、ソフトウェアでも「生成の責務」を分けることで、
利用側のコードを安定化させることができます。

パターンを構成する4つの要素

Factory Methodパターンは、4つの主要クラスで構成されます。

要素	役割	C#での表現例
Product	製品の共通インターフェース	`IReport`
ConcreteProduct	実際の製品クラス	`PdfReport`, `ExcelReport`
Creator	生成を定義する抽象クラス	`ReportCreator`
ConcreteCreator	実際に製品を生成するクラス	`PdfReportCreator`, `ExcelReportCreator`

構造を図で表すと以下のようになります：

Creator ── Create() ──▶ Product
   ▲                        ▲
   ├─ ConcreteCreatorA → ConcreteProductA
   └─ ConcreteCreatorB → ConcreteProductB

Creator（工場）は「作る手順」を定義し、
実際に「何を作るか」はサブクラス（ConcreteCreator）が決めます。

最小のC#実装で理解するFactory Method

では、実際に動く最小のサンプルを見てみましょう。

// 製品の共通インターフェース
public interface IReport
{
    void Export();
}

// 具体的な製品
public class PdfReport : IReport
{
    public void Export() => Console.WriteLine("PDFレポートを出力しました。");
}

public class ExcelReport : IReport
{
    public void Export() => Console.WriteLine("Excelレポートを出力しました。");
}

// Creator（抽象クラス）
public abstract class ReportCreator
{
    public abstract IReport CreateReport();

    public void Execute()
    {
        var report = CreateReport();
        report.Export();
    }
}

// 具体的Creator
public class PdfReportCreator : ReportCreator
{
    public override IReport CreateReport() => new PdfReport();
}

public class ExcelReportCreator : ReportCreator
{
    public override IReport CreateReport() => new ExcelReport();
}

// 実行
class Program
{
    static void Main()
    {
        ReportCreator creator = new PdfReportCreator();
        creator.Execute();  // PDFレポートを出力しました。

        creator = new ExcelReportCreator();
        creator.Execute();  // Excelレポートを出力しました。
    }
}

出力結果

PDFレポートを出力しました。
Excelレポートを出力しました。

このパターンが活きる場面

Factory Methodパターンは、「生成対象が複数ある」「拡張される可能性が高い」
そんな場面で特に力を発揮します。

よくある3つの実例

GUIアプリ
　→ OSやテーマごとに異なるボタン／ウィンドウを生成
データベースアクセス
　→ SQLServer／MySQL／PostgreSQL 用クライアントを切り替え
AIモデル選択
　→ GPT／Claude／Gemini などを実行時に選択

これらは、どの製品を使うかをサブクラスに委ねるだけで差し替えが完了します。
クライアントコードは new を知らないので、変更に強く保守しやすい構造になります。

Factory Methodを使うメリット（簡単な先取り）

詳細は次回記事で詳しく解説しますが、
この設計を導入すると以下の効果が得られます。

メリット	内容
拡張性	新しい製品を追加しても既存コードに影響なし
保守性	「生成の責務」を1か所に集約できる
再利用性	Creatorを共通化して異なる製品に流用可能