Question for readers of Head First Design Patterns

[B.Sathish]

I have question related to chapter 4 (Baking with OO goodness) - the factory pattern.

My question is what are the advantages offered by the Factory method pattern over the Simple Factory programming idiom? Why do we need Factory method when we have the Simple Factory idiom?

My argument is that the Simple Factory idiom is based on composition and delegation while the Factory method is based on inheritance. After reading the first 3 chapters, it is obvious that we should favor composition over inheritance due its advantages (dynamic behavior changes and flexibility). This being the case why need to use the Factory method pattern? What is it that you can do with the Factory method that you cannot do with the Simple Factory more flexibly and dynamically?

The book says that the Factory method pattern localizes the factory (the factory method) and the client (calling method) to the same class and hence the same framework and you can enforce tighter control on the client by making the client method final. These arguments are somehow not that appealing to me. Also with the Simple Factory, you can compose a Factory interface and delegate the call at run-time to any concrete factory class implementing that interface. This is more dynamic and flexible than having the factory implementation in a sub-class

Would like to know your views on this.

[Ilja Preuss]

The gist is that the enhanced flexibility that comes with composition also comes with a cost: more code. If the flexibility isn't needed, it just increases the cost of the system by unnecessarily increasing the complexity of the design.

In my not so humble opinion, the whole notion of "favouring composition over inheritance" is an overreaction to the fact that inexperienced developers tend to *overuse* inheritance. That doesn't mean that inheritance doesn't have it's place (to Tony: at least in languages that make composition result in more complex code). A good designer simply knows the forces that lead to choose one over the other, and when and how to *refactor* from one to the other.

One force that leads me to choose Factory Method (or the more general Template Method) pattern is the fact that the *logic* itself already is tightly coupled. If that's the case (and doesn't hurt), there often isn't value in decoupling the code.

For example, take the Abstract Testcase pattern. It defines an abstract unit test class that tests the contract of, say, an interface and defines an abstract factory method that subclasses override to create the object under test. As the subclasses, and the creation of the object under test, are very tightly coupled to the use in the abstract test class, there would be no value in using something more decoupled - it would just make initialization of the test runs more complex.

Does that sound reasonable?

[B.Sathish]

Your argument of the logic being tightly coupled to the client of the factory seems reasonable. But I think this can be used as an argument in many practical situations to prefer inheritance over composition

[Ilja Preuss]

Originally posted by B Sathish:
Your argument of the logic being tightly coupled to the client of the factory seems reasonable. But I think this can be used as an argument in many practical situations to prefer inheritance over composition

Mhh, true. And if you think hard, you probably almost always can come up with some kind of abstraction that also logically decouples the two. I guess what I'm saying is that this does come with a cost, and simply isn't always worth it...

[Rafael De la Guetto]

I have had exactly de same issue as B.Sathish, i found no advantage on Factory Method regarding to Simple Factory.

But the annoying thing, and what disturbs me is that the "arguments" given by the book seems to be "false" (at least to me).

It says, for example, on the page 135, the last question:

By subclassing the PizzaStore class, you decide what concrete products go into making the pizza that (orderPizza() returns. Compare that with SimpleFactory, which gives you a way to encapsulate object creation, but doesn't give you the flexibility of the Factory Method because there is no way to vary the products you're creating.

Which is false, the flexibility to vary the products you're creating is the same in both cases (you have to change 1 method of 1 class in both cases). And it is not the only doubtful assumption made in this chapter, in the page 119 you can find an introduccion to the Factory Method pattern as an improvement to Simple Factory, but the reasons it gives dont seem to be true to me...

As Ilja Preuss says, maybe less lines of code are needed, but i find it not crucial (because the welness of a pattern is not measured in terms of lines of code) and, anyway, this weak reason is not alluded by the book neither!

But let me go further:
The 3rd part of the chapter, the Abstrac Factory Patter has NO DIFFERENCE (to my eyes) with the Simple Factory!!! It is the same case, with the only difference that instead of 1 method like

getInstance("A")

The methods are not parametrized!! like as follows:

getInstanceA()
getInstanceB()

But if you substitute the ingredients by pizzas, you have got exactly the same structure.

Are they kidding? or am I wrong?

Regards!