ファクトリーパターンとは？──オブジェクト生成を柔軟に制御する設計の入り口

はじめに

new クラス名()

で直接インスタンスを作成するのは簡単ですが、その構造が複雑になると依存関係が強まり、保守性が低下します。
「インスタンスの作り方」を1カ所に集約し、柔軟でテストしやすい設計に導くのが**ファクトリーパターン（Factory Pattern）**です。
本記事では、Factoryの基本構造、活用シーン、サブタイプ、実装例をわかりやすく紹介します。

基本情報・概要

ファクトリーパターンは、インスタンス生成の責任を専用の「工場クラス（Factory）」に委譲することで、クライアントコードから依存を切り離す設計パターンです。

主な目的：

• クラス生成の仕組みを隠蔽（カプセル化）
• 条件に応じたインスタンスを返せる柔軟性
• 実装の変更が他のコードに波及しにくい

GoFパターンでは「Factory Method パターン」として分類されています。

比較・分類・特徴の表形式まとめ（任意）

「オブジェクトを直接 new しない」ことで、柔軟な拡張性・テスト性・依存の分離が得られます。

深掘り解説

✅ Simple Factory の例（JavaScript）

class Dog {
  speak() { return "ワン"; }
}

class Cat {
  speak() { return "ニャー"; }
}

class AnimalFactory {
  static create(type) {
    if (type === "dog") return new Dog();
    if (type === "cat") return new Cat();
    throw new Error("Unknown animal type");
  }
}

const pet = AnimalFactory.create("dog");
console.log(pet.speak());  // ワン

このように

create()

メソッドがインスタンス生成の責任を持ち、呼び出し元は「何を使うか」だけ指定すればOKです。

✅ Factory Method の構造（概念）

Creator（抽象） ---> factoryMethod()
    ↓
ConcreteCreator（具体） ---> 実際のクラスを生成

→ クライアントは

factoryMethod()

を呼ぶだけで、具体クラスを意識せずに利用できます。

応用・発展的な使い方

• DI（依存性注入）との併用：インスタンス生成の切り替えを柔軟に
• 環境ごとの実装切り替え：

  isProduction

  で異なるクラスを返すなど
• テスト用Mockの注入：テスト時だけダミー実装を返す
• Abstract Factory：UIテーマや設定ごとの複数オブジェクト生成に対応

Factoryは「newを1カ所に閉じ込めることで、全体の設計を柔軟にする」戦略です。

よくある誤解と注意点（任意）

• 「Factoryだから複雑な構造が必要」ではない：最小限でも十分に効果あり
• 乱用すると階層が深くなる：小さなプロジェクトでは過剰設計になる場合も
• Abstract Factoryは依存が複雑化しやすい：組み合わせの設計に注意が必要
• クラス名が曖昧になる問題：

  create()

  より

  createUserService()

  など明確に

Factoryは設計を隠す武器ですが、隠しすぎると読みにくくなる点に注意です。

まとめ

ファクトリーパターンは、インスタンス生成の柔軟性と保守性を高めるための基本設計パターンです。
直接

new

する代わりに、Factoryを通じてオブジェクトを作ることで、依存関係を制御し、実装変更にも強い構造が実現できます。
小さなFactoryから始めて、徐々にFactory MethodやAbstract Factoryへとスケールさせていきましょう。