Confusion about Factory method pattern

Hmm... I was going through Factory method pattern from GOF book, later looked in "The Design pattern" book by James W. Cooper. I consider GOF book as reference. My one of the confusion I believe is going to be clear now.

If you compare the two books, it’s my thought that NamerFactory class in Cooper book is basically one of the abstraction identified by GOF (Application) and 'Namer' relates to "Document" in GOF.

I think in Cooper book, there should be one more class ConcreteNamerFactory or MyNamerfactory that should inherit from NamerFactory to make the example more complete.

So we should have overall 6 classes:

Cooper                                   GOF

-------                                     -----

Namer                                    Document

FirstFirst                                MyDocument

LastFirst                                 MyDocument

NamerFactory                        Application

ConcreteNamerFactory         MyApplication

Above diagram is from GOF Book.

Below should be the steps to create an instance of Namer:

1) NamerFactory factory = getFactory(String whichFactory);//This method localize the code for searching apprpriate factory and in simple language, will have some if-else logic to choose appropriate factory based on provided parameter (whichFactory). Call to this method and selection of appropriate factory is out of scope for 'Factory method' design pattern. I mentioned this to give a complete picture.

Above line of code could also be written as:

NamerFactory factory = new ConcreteNamerFactory();

2) Namer namer = factory.getNamer(); // This piece of code does what GOF book says:

• Creator relies on its subclasses to define the factory method so that it returns an instance of the appropriate ConcreteProduct.

Here 'creator' refers to an instance of 'NamerFactory' that is an abstraction in our application. However NamerFactory  is delegating the responsibility of creating an instance of a concrete product i.e. 'Namer' to one of its sub classes i.e. 'ConcreteNamerFactory'.

Within getNamer() method of 'ConcreteNamerFactory' you can write all the code for instantiating your concrete product.

Following DDD patterns, factory pattern also gives you flexibility to externalize any knowledge your product needs for its creation. A nice example I remember, Printer cannot build itself, actually they are built in assembly line by providing all construction material. 'Factory' also does job of assembly line and build your Printer object; this relax printer (i.e. your product) from knowing how to build myself (i.e. instead of placing complex creation logic in Object's constructor, better place it outside).

To summarize:

• -          Factory method pattern is helpful when you’ve to create a single Product(or Namer)

• -          This will allow you to delegate the responsibility for creating one Product to a subclasse.

• -          If you’ve multiple Product(or Namer) to create, still you’re fine using this patter i.e. assuming you’ve different kind of Namers (FIrstNamer, LastNamer, MiddleNamer, NoNamer etc..), you can write as many method in NamerFactory class and get those Objects created..

-          However, If apart from different kind of Namers, you also have different Namer families..then you need to look for my next Blog.

To conclude and to simplify things further , let’s considering an application that uses JDBC with Oracle database. However we also expect that in order to run our application with SQL Server DB, we need to only change the driver..rest JDBC will take care. This works because we use Connection, Statements, ResultSet abstraction in our application for which concrete classes reside inside Oracle provided client libraries and we simply don’t worry about them. Somewhere in the whole flow, a factory method resides that generate these objects for us. By the time, we are using Oracle consistently, we are happy because our factory methods instantiate appropriate Connection, Statements and ResultSet objects.

So factory pattern no doubt is an essential part of our application  development.