2

In Factory method pattern there are 2 lead implementation (correct me if I'm wrong):

When Creator class is being abstract and not providing an implementation for the Factory method:

public abstract class CasinoGameCreator {

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

public abstract ICasinoGameType createGame();

Or, we can have the Creator class be a concrete class that provides implementation for the 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;
        }
    }
}

Is there any strong preference when to use each implementation? if there is, in what general situations we whould prefer using the 1st approach over the 2nd?

GhostCat
  • 137,827
  • 25
  • 176
  • 248
Nimrod
  • 1,100
  • 1
  • 11
  • 27
  • I believe you're referring to the [Abstract Factory Pattern](https://dzone.com/articles/intro-design-patterns-abstract) and the [Factory Method Pattern](https://dzone.com/articles/gof-design-patterns-factory-me). Possible answers to your question on SO [can be found here](http://stackoverflow.com/questions/5739611/differences-between-abstract-factory-pattern-and-factory-method) – Tagc Aug 07 '16 at 18:40
  • 1
    Your second example is not a [Factory Method Pattern](http://www.oodesign.com/factory-method-pattern.html), but a [Factory Pattern](http://www.oodesign.com/factory-pattern.html). Did you actually intend to compare two different patterns? Or did you misunderstand what the two options for Factory *Method* Pattern is? – Andreas Aug 07 '16 at 18:48
  • @Andreas - I was sure they are the same `Factory Method pattern`, so I guess I misunderstood, though the 2nd example are took from _Cracking the coding, 6th edition_ book, so this is very strange to me... – Nimrod Aug 07 '16 at 19:01

1 Answers1

1

Option 1 is following the Open/closed principle. This means: it is open for extensions (as different subclasses can implement different ways of creating a game); but it is closed for modification - the behavior of playGame() is fixed. Well, it is not; but if you use this pattern, you really would want to make playGame() to be final. If you have such an abstract class with an implementation X; and an abstract method Y (used within the other method X); than it doesn't much sense to allow subclasses to change X.

Option 2 is helpful when you are really sure about the different type of games; meaning: chances that this enum will ever change are small. Given the idea of games in casino; I very much doubt that this would be true here. Probably you could add a new game every other day. And then, you have to turn to each place that switches over the GameType and adapt that code.

So, given those thoughts, option 1 would be the first choice - because you can simply add a new game type by creating a new subclass of your creator class. This means: you can add a new game without touching the code responsible for other games.

Of course: if you would pick a different example, the requirements might be different, and then option 2 might have certain benefits.

GhostCat
  • 137,827
  • 25
  • 176
  • 248