mcpField
G
gof-factory

gof-factory

github.com/yonatankarp開発143 回インストール23 週間前に更新
リポジトリ

gof-factory について

gof-factoryは、オブジェクト生成の設計パターンを学ぶ開発者向けスキルです。Simple Factory、Factory Method、Abstract Factoryの適用範囲と使い分けを解説します。

主な機能

  1. 01Simple Factoryの指針
  2. 02Factory Methodの指針
  3. 03製品群向けAbstract Factory
  4. 04選択の目安とアンチパターン

活用シーン

  1. 01設定に応じた実装の選択
  2. 02サブクラスによる生成型の決定
  3. 03関連オブジェクト群の一貫した生成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yonatankarp/software-design-skills --skill gof-factory

インストール後、Claude Code で/gof-factoryを入力して読み込まれたか確認します。

詳細

1 行でまとめると

どの具象クラスをインスタンス化するかの選択を一元化し、クライアントから隠します。適用範囲が広がる 3 つの形式があります。Simple Factory(1 つのメソッドが型を選択)、Factory Method(サブクラスが型を選択)、Abstract Factory(関連する型のファミリーを生成)です。

このスキルを使う場合

  • クライアントコードに new ConcreteX() を使うかどうかの判断が散在しており、その選択が入力データ、設定、環境に依存している。
  • 2 つの並行する階層で、対応する実装をまとめて選択する必要がある(例:NYStylePizzaStore が NYStyleDough と NYStyleSauce を生成する場合。これは Abstract Factory です)。
  • 周囲のワークフローを共有しながら、どの具象型をインスタンス化するかはサブクラスに決定させたい。これは Factory Method です。
  • 生成時に、コンストラクターだけでは強制できない不変条件がある。

このスキルを使わない場合

  • 具象型が 1 つしかない場合。コンストラクターを直接呼び出してください。
  • シンプルなトップレベル関数(fun parsePayment(json): Payment)で十分な場合。単一の関数に *Factory というクラス名を付けても何も得られません。
  • 生成が本当に単純で、「ファクトリーはベストプラクティスだから」という理由だけで間接層を追加する場合。それは形式だけの儀式です。

主な内容

適用範囲が段階的に広がる 3 つの形式があり、それぞれ、より具体的な問題を解決します。

Simple Factory(厳密には GoF パターンではありませんが、入り口となるパターンです)。判別子(文字列、列挙型、フラグ)を受け取り、適切な具象インスタンスを返す単一のメソッドまたはクラスです。new を一元化します。判別子が呼び出し側で分かっている場合に有効です。

Factory Method。具象クラスの選択をサブクラスに委ねます。基底クラスは factoryMethod()(抽象メソッド)を含むワークフローを実装し、各サブクラスは適切な具象型を返すようにこのメソッドをオーバーライドします。周囲のワークフローは共通でも、生成する型がサブクラスごとに異なる場合に使います。

Abstract Factory。関連するプロダクトの ファミリー を生成するファクトリーです。ファクトリーインターフェイスでは、プロダクトの型ごとに 1 つのメソッドを宣言します(例:createDough、createSauce)。具象ファクトリーは、互いに対応したスタイルの実装を生成します。型を対応するセットとして生成する必要がある場合に使います。

判断のヒント

  • まずは Simple Factory から始めます。ワークフローの継承階層が実際に必要な場合にのみ Factory Method に進みます。プロダクトファミリーの一貫性を保つ必要がある場合にのみ Abstract Factory に進みます(NY スタイルには NY スタイル、シカゴスタイルにはシカゴスタイルを使い、決して混在させません)。
  • 対象クラス自体にある単一の静的生成メソッド(例:Pizza.of(type))で十分なこともよくあります。別のファクトリークラスを反射的に追加しないでください。
  • 永続化やグローバル状態の変更も行うファクトリーは、役割を担いすぎています。生成処理は副作用のないものに保ちます。

アンチパターン

  • コンストラクターで十分なのに、型ごとにファクトリークラス(OrderFactory、CustomerFactory、AddressFactory)を作ること。パターンを使うこと自体が目的になっています。
  • 「FactoryFactory」。ほとんどの場合、過剰設計の兆候です。
  • 具象ファクトリーが 1 つしかないのに Abstract Factory を使うこと。その抽象化が対応するべき複数性がありません。

関連項目

  • gof-singleton — ファクトリーはシングルトンであることがよくあります。トレードオフを検討してください。
  • gof-strategy — ファクトリーはしばしばストラテジーを 生成 します。この 2 つは組み合わせて使えます。
  • gof-kotlin-idioms — Kotlin の companion object ファクトリーメソッド、when によるマッチングを使った sealed class のファクトリー、コンストラクター関数式を使えば、ほとんどの場合、個別のファクトリークラスを作らずに済みます。

参考資料

  • Head First Design Patterns(第 2 版)、第 4 章(「Baking with OO Goodness: the Factory Pattern」)— ピザ店の例を使い、Simple Factory、Factory Method、Abstract Factory を解説しています。

コメント