GoFデザインパターン23個を完全に理解するブログ #03 Abstract Factory(抽象ファクトリ)

2025/10/29

プログラミング

t f B! P L
eyecatch 抽象ファクトリは、ファクトリメソッドを理解してから覚えるデザインパターンです。 関連する一連のオブジェクトをまとめて作る設計なので、デザインパターンも効率的に学習していきましょう。

Abstract Factory(抽象ファクトリ)とは?

「関連するオブジェクト群を、統一されたインターフェースで生成する」パターン。 要するに、「シリーズものの商品を、まとめて作るファクトリ」を、さらにまとめる仕組み。 例えてみると、マクドナルド工場」と「モスバーガー工場」はどちらもバーガーとポテトを作れるけど、味や見た目が違う。 でも、どちらのブランドも、注文の仕方は同じ手順というのがミソ。

サンプルコード

今回も、Javascriptを使って、サンプルプログラムで理解していきましょう。

プロダクト群(作られる側)

// --- マクドナルド --- class McBurger { name() { return "マクドナルドのバーガー"; } } class McPotato { name() { return "マクドナルドのポテト"; } } // --- モスバーガー --- class MosBurger { name() { return "モスのバーガー"; } } class MosPotato { name() { return "モスのポテト"; } }

抽象ファクトリ(工場の「型」)

class FastFoodFactory { createBurger() {} createPotato() {} }

具体的なファクトリ(ブランドごとの実装)

class McFactory extends FastFoodFactory { createBurger() { return new McBurger(); } createPotato() { return new McPotato(); } } class MosFactory extends FastFoodFactory { createBurger() { return new MosBurger(); } createPotato() { return new MosPotato(); } }

利用側(どのブランドでも同じ手順で使える)

function orderSet(factory) { const burger = factory.createBurger(); const potato = factory.createPotato(); console.log(burger.name()); console.log(potato.name()); } orderSet(new McFactory()); // → マクドナルドのバーガー // → マクドナルドのポテト orderSet(new MosFactory()); // → モスのバーガー // → モスのポテト

ポイント解説

Factory Method → 単体の「オブジェクトを1つ」作る。 Abstract Factory → 関連する「オブジェクトのセット」をまとめて作る。

メリット

ブランド(またはテーマ)を切り替えても、同じインターフェースで操作可能になる。 プロダクト群の一貫性を保てる(例:UIテーマやプラットフォームごとの差異)ので依存関係を疎結合にできる。

デメリット

ファクトリメソッドと同じくクラスが多くなりがち(構造が複雑)なので、命名規則などに注意を払う必要があります。 小規模アプリではオーバーエンジニアリングになりやすいので、効率化を追求する開発組織には合わないかも。

使用に適した場面

OSごとのUI部品(Windows / macOS / Linux)。 ゲームでのキャラのスキン切り替えなど。 Webアプリで「ライトモード / ダークモード」のテーマ生成。 データベース接続(MySQL / PostgreSQL など)。

あとがき

多段のファクトリーメソッドのようなイメージですが、ストレートにコードを見ただけでは、少し追うのが大変な印象です。 class内のメソッドをモデル化して、それをオブジェクトとして扱うようなイメージでみると、少しだけわかりやすくなりました(個人的に) 実際のコードは、もっど複雑になりますが、プロダクトの中はまるで違う処理を、その上位手続(ファクトリ)は、同じ手順で処理するようにまとめるのがコツでしょうね。 これを実際に使いこなすには、プログラミング経験をたくさん積んで、共通かできる処理と、末端の独自処理を階層構造で理解できるようにならないと難しいようです。 いきなり、大規模開発で使うのではなく、ミニマムな機能開発などで何度も作り込んで、ファクトリ構造を理解するところから始めるのがいいでしょう。 ちなみに、個人的には、独自フレームワークのORM(共通データベースアクセス処理)で、このデザインパターン使っていました。

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ