Assign the responsibility for creating objects that belong together to one class.

Define a basic abstract type, so you can decide on the fly, which special set of objects you like to produce. For instance in Java you might define an abstract factory for the window components you use. You may later work with AWT or Swing. For these two, you define concrete factories with their FactoryMethod's.

For the examples: I'm writing a program that could use several different implementations of a ResourceDescriptionFramework Database. I don't want to tie the program to any particular implementation. Two different implementations are JenaDatabase and SesameDatabase classes. Each implementation is an adapter (see AdapterPattern and StrategyPattern) around the third-party databases (Jena and Sesame respectively). Each class also implements the RdfDatabase interface. Here's a diagram:

Here's the problem: I've also got a client of RdfDatabase that needs a concrete implementation to work with (i.e., to search for something in the database). I shouldn't do this, since every time I switch implementations of RdfDatabase I need to edit the source of a big file and recompile it:

Here's how a FactoryMethodPattern solves the problem: Basically, a Factory Method is like a Template (see TemplatePattern) with the implementation of the method that creates the object left to subclasses. Say

This localizes where the decision is made on which database to use. I don't risk making a mistake or introducing bugs into code unrelated to creating databases since it is in a different class (i.e., TemplateClient). Here's a diagram of how everything fits using the original names:

Here's a different, unrelated problem: In the previous case, there was only a single class being used by the AbstractCreator. But what if there were twenty classes being created? Say those twenty classes were highly coupled and depended on each other. A programmer who extends AbstractCreator would have to write twenty factory methods to keep up, and that CodeSmells.

Even with only a few (highly-coupled) classes, an inexperienced programmer could write methods that use two incompatible implementations. Here's an example of this problem: Instead of a single RdfDatabase, you also needed an RdfWriter that used a particular engine:

Now that looks a lot like the bad code. However, there is a subtle improvement. You see, the programmer who writes implementations of the highly-coupled classes (JenaDatabase and JenaWriter, for instance) usually isn't writing the client which uses them. The highly-coupled classes form a framework which other client-programmers use. Well, the framework-programmer (don't confuse with the client-programmer) will write the factory class that contains the FactoryMethods for each of class in the framework. Here's a revised client:

Notice: I used a factory-method to choose the factory-class to use (I named it createRdfFactory to avoid confusion with the alternative, RdfFactoryFactory). The following uses just the AbstractFactoryPattern, but is a less-flexible design:

Also note that the factory-class uses factory-methods to create each individual object. The functions databaseFactory() and writerFactory() are factory-methods. Factory-classes could use different ways to create each object (like using a PrototypePattern), but factory-methods are most common.

Wont we have the same problem which you have tried to avoid by using AbstractFactory?

No, the problem in my example was that incompatible classes are created. Neither my implementation nor your implementation makes that mistake. Design-wise, there is no problem with your implementation!

The problem in your 'Jena2Client' class is that is really a Sesame Client, just poorly named. I could have named my implementation:

As you can see, the factory method makes it is easy to switch abstract RdfFactory implementations. (Note that there are other ways of accessing Factories as well - many use StaticFactory idioms in the abstract class, but I don't like that method.)-- JimmyCerra

That's a nice example. We can say that an AbstractFactory provides an interface for a collection of Factory methods and also provides a mechanism for the creation of concrete factories.
-- Shakir

Thanks. The intent of an AbstractFactory is simply to provide an interface for a creating a set of related, possibly interdependent objects. Although an AbstractFactory often uses FactoryMethods - as the above example does - they are not limited to them. Alternatives include (but are not limited to) Abstract Factories that use:

PrototypePattern (builds objects by copying and customizing a prototype of the object)

In real life, patterns aren't really segregated by clear lines. Often, a class uses one or several patterns, or several patterns look the same (but have different intents driving the refactorization). So it is possible for an AbstractFactory to use FactoryMethods? with a PrototypePattern or FactoryMethod.
-- JimmyCerra