gof-factory について
gof-factoryは、オブジェクト生成の設計パターンを学ぶ開発者向けスキルです。Simple Factory、Factory Method、Abstract Factoryの適用範囲と使い分けを解説します。
主な機能
- 01Simple Factoryの指針
- 02Factory Methodの指針
- 03製品群向けAbstract Factory
- 04選択の目安とアンチパターン
活用シーン
- 01設定に応じた実装の選択
- 02サブクラスによる生成型の決定
- 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 を解説しています。