ファクトリメソッドのパターン - 「作成者」クラスはいつFactoryメソッドを実装する必要がありますか？ <code>Factory method</code>パターンでは

Question

2リード実装（私が間違っているなら、私を修正）があります。

CreatorクラスはabstractであるとFactory methodのための実装を提供していないとき：

public abstract class CasinoGameCreator { 

public void playGame() { 
    ICasinoGameType gameType = createGame(); 
    gameType.play(); 
} 

public abstract ICasinoGameType createGame(); 

かをの場合、クラスは、Factory methodの実装を提供する具体的なクラスにすることができます。

public class CasinoGame { 

    public static CasinoGame createGame(GameType type) { 
     if (type == GameType.BlackJack) { 
      return new BlackJackGame(); 
     } else if (type == GameType.Poker) { 
      return new PokerGame(); 
     } else { 
      return null; 
     } 
    } 
} 

各実装を使用する際には、どんな強みがありますか？もしあれば、どのような一般的な状況で私たちは第2アプローチよりも第1アプローチを好むだろうか？

Answer 1

オプション1は、Open/closed principleに従います。これは、拡張機能のためにオープンされていることを意味します（異なるサブクラスがゲームを作成するさまざまな方法を実装できるため）。それは修正のために閉じられています - playGame（）の動作は修正されています。まあ、そうではありません。このパターンを使用すると、実際にplayGame（）をfinalにしたいと思うでしょう。実装Xを持つ抽象クラスがある場合は、および抽象メソッドY（他のメソッドX内で使用される）サブクラスがXを変更できるようにするのはあまり意味がありません。

オプション2は、さまざまな種類のゲームについて本当に分かっている場合に役立ちます。つまり、この列挙型が変更される可能性は小さいです。カジノでゲームのアイデアを考えると、私はこれが本当であることを非常に疑う。おそらくあなたは一日おきに新しいゲームを追加することができます。そして、GameTypeを切り替える各場所に移動し、そのコードを適合させなければなりません。

これらの考えを考慮すると、クリエイタークラスの新しいサブクラスを作成するだけで新しいゲームタイプを追加できるので、オプション1が最初の選択肢になります。つまり、その他のゲームを担当するコードに触れることなく新しいゲームを追加できます。

もちろん、別の例を選択する場合、要件が異なる可能性があり、オプション2に一定の利点があるかもしれません。