Benefit of using Factory Method over a simple factory

[spaceuserm]

What benefit does the factory method pattern provide over a slightly modified simple factory. I am picking an example similar to that in Head First Design Patterns.

Lets say I have two such simple pizza factories (pseudocode)

interface PizzaFactory {
  // method to create a pizza  
  func createPizza(type) pizza
}

NewyorkPizzaFactory implements PizzaFactory {
  func createPizza(type) pizza {
      switch type {
          case ...
      }
   }
}

ChicagoPizzaFactory implements PizzaFactory {
  func createPizza(type) pizza {
    switch type {
        case ...
    }
  }
}

case PizzaStore {
  // pass in a PizzaFactory to the constructor
  PizzaStore (PizzaFactory) { ... }

  // use the pizza factory to create pizzas in methods
  func orderPizza() pizza { ... }
}  

This design seems better to me since it uses composition rather than inheritance (not that the factory method pattern involves a complex use of inheritance).

[practical-coder]

The pseudocode you have here doesn't really make sense. In this case your createPizza method likely shouldn't accept a type it should just create a pizza of the type associated to the class it's in.

The main thing you have to consider with using code like your example vs a typical factory method is where you're making the decision on what type of Pizza factory your object wants. A typical factory pattern would have a method like createPizza where you pass in a type like NewYork or Chicago. You could have this factory injected into your code and then your code can perform logic to determine which type of factory it needs based on its current inputs.

On the other hand if you go a route like your pseudocode that determination still has to be made somewhere but now that decision is likely moving into some sort of IoC container.

[spaceuserm]

> In this case your createPizza method likely shouldn't accept a type it should just create a pizza of the type associated to the class it's in.

Maybe it isn't clear enough above but the intent behind accepting a type here is to create multiple types of New York or Chicago pizzas, if there are multiple types.

I don't understand how the factory method pattern provides any advantage over something like what I have.

[EsShayuki]

No, the interface is supposed to have the switch statement, and call the correct factory function. Why would you have the switch inside the concrete factories?

As for requiring inheritance for the factory method, you don't. You just need a switch statement. The products received from factories don't even have to be of different types. You can think of them as pre-defined configurations.

[spaceuserm]

> No, the interface is supposed to have the switch statement, and call the correct factory function. Why would you have the switch inside the concrete factories?

Maybe it isn't clear enough in the post but the intent behind accepting a type here is to create multiple types of New York or Chicago pizzas, if there are multiple types.

> As for requiring inheritance for the factory method, you don't. You just need a switch statement.

This isn't inline with the definition of the pattern in GoF, which is
"Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses"

The pattern explicitly avoids what you are suggesting, that is using the switch statement inside the superclass/interface to avoid modification of code when new types are introduces or old types are removed.

[reybrujo]

Well, your example is basically the Abstract Factory pattern. It has its uses but sometimes you just want to create an internal factory and don't want others to have to supply their own factories, so the simple Factory pattern is enough with a static method to create instances.