I'm finding myself getting a bit muddled by these two patterns while reading DesignPatternsBook.

Both classes have abstract classes (Abstract Factory, Abstract Product in Abstract Factory & Abstract Creator and Abstract Product in Factory Method). Both have subclasses that customize the classes for specific use - (Concrete Factory, Concrete Product, Concrete Creator, Concrete Product).

So what's the difference between Factory and Creator? Both
* have specific subclasses for specific applications/versions of products
* have specific product classes created by the subclasses

In the Create Maze Examples -

The Factory knows WHAT to create and gets its instructions on WHEN from another object (Instruction through ObjectComposition)

The Creator knows WHAT to create and has a shared method that tells it WHEN to create another object. (Instruction through Inheritance)

But the book also says
''Abstract Factory is often implemented with factory methods.'' So perhaps WHEN is not important.. and I'm missing something obvious here.

So:

Is FactoryMethodPattern simply: Each subclass knows what other classes to use/objects to create.

AbstractFactoryPattern is: Swapping FactoryMethod Classes with Object Composition

With FactoryMethodPattern, the method is in the object that uses it. With AbstractFactoryPattern, it's moved to a separate factory object. It's the difference between "Foo foo = this.createFoo();" and "Foo foo = factory.createFoo();" -- JasonArhart

----
In my understanding, the difference between FactoryMethod and AbstractFactory is similar to the one between TemplateMethod and the StrategyPattern - the former uses inheritance to get the concrete implementation, the latter composition.
-- Anonomyous Genius

----
FactoryMethod is a basic pattern. It is always used when you work with the AbstractFactory pattern.
The AbstractFactory adds two ideas to the idea of the FactoryMethod:
*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.
-- HanspeterHeeb

----
I've read GangOfFour's DesignPatternsBook among others, but their explanations are often kinda vague. The HeadFirstDesignPatterns Book has an excellent section devoted to this very topic. I suggest you refer to it. Here's how I understand the difference between AbstractFactory''''''s and FactoryMethod''''''s (using the JavaLanguage):

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 Jena''''''Database and Sesame''''''Database classes. Each implementation is an adapter (see AdapterPattern and StrategyPattern) around the third-party databases (Jena and Sesame respectively). Each class also implements the Rdf''''''Database interface. Here's a diagram:

	Rdf''''''Database
		^
		|
		|
		+-- Jena''''''Database --uses---------------> Jena
		|
		|
		+-- Sesame''''''Database --uses-------------> Sesame
Here's some code explaining their relationship:

	public interface Rdf''''''Database {}
	public class Jena''Database implements Rdf''''''Database {}
	public class Sesame''''''Database implements Rdf''''''Database {}
Here's the problem: I've also got a client of Rdf''''''Database 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 Rdf''''''Database I need to edit the source of a big file and recompile it:

	public class Bad''''''Client {
	  public Map queryDatabase(String queryString) {
		private Rdf''''''Database db = new Jena''''''Database();
		
		checkQueryIsValid(queryString);
		
		return db.find(queryString);
	  }
	}
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 

	public abstract class Template''''''Client {
	  public Map queryDatabase(String queryString) {
		Rdf''''''Database db = databaseFactory();
		
		checkQueryIsValid(queryString);
		
		return db.find(queryString);
	  }
	  public abstract Rdf''''''Database databaseFactory();
	}
Note: Normally I'd call the factory method "createDatabase" or something like that. I simply labelled it databaseFactory to indicate that the factory method is that particular method.

Now, in order to use the Template''''''Client, I need to subclass it and provide the implementation of the appropriate database. If I needed Jena, I could use:

	public class Jena''''''Client extends Template''''''Client {
	  public Rdf''''''Database databaseFactory() {
		return new Jena''''''Database();
	  }
	}
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., Template''''''Client). Here's a diagram of how everything fits using the original names:

	Abstract''''''Creator --uses--------------> Abstract''''''Product
		^					^
		|					|
		|					|
	Concrete''''''Creator --creates-----------> Concrete''''''Product
That's how the FactoryMethod pattern works.

Here's a different, unrelated problem: In the previous case, there was only a single class being used by the Abstract''''''Creator. 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 Abstract''''''Creator would have to write twenty factory methods to keep up, and that CodeSmell''''''s.

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 Rdf''''''Database, you also needed an Rdf''''''Writer that used a particular engine:

	Rdf''''''Database
	  ^	^
	  |	|
	  |	|
	  U	+-- Jena''''''Database --uses---------------> Jena
	  S	|
	  E	|
	  S	+-- Sesame''''''Database --uses-------------> Sesame
	  |
	  |
	Rdf''''''Writer
		^
		|
		|
		+-- Jena''''''Writer --uses-----------------> Jena
		|
		|
		+-- Sesame''''''Writer --uses---------------> Sesame
A concrete client that implements an abstract class which uses the factory method doesn't protect mistakes like:

	public abstract class BadTemplate2Client {
	  public Map writeDatabase() {
		Rdf''''''Database db = databaseFactory();
		
		Rdf''''''Writer ww = writerFactory();
		
		return ww.doSomethingWith(db);
	  }
	  public Rdf''''''Database databaseFactory();
	  public Rdf''''''Writer writerFactory();
	}


	public class BadJena2Client extends BadTemplate2Client {
	  public Rdf''''''Database databaseFactory() {
		return new Jena''''''Database();
	  }
	  public Rdf''''''Writer writerFactory() {
		return new Sesame''''''Writer();
	  }
	}
Whoops! That could cause lots of runtime problems if Sesame''''''Writer can't be used with Jena''''''Database. However, this will compile without an error message.

Here's how the AbstractFactoryPattern solves this. It is a single class that just makes the highly-coupled classes:

	public abstract class Rdf''''''Factory {
	  public Rdf''''''Database databaseFactory();
	  public Rdf''''''Writer writerFactory();
	}
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 (Jena''''''Database and Jena''''''Writer, 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 FactoryMethod''''''s for each of class in the framework. Here's a revised client:

	public abstract class Template2Client {
	  public Map writeDatabase() {
		Rdf''''''Factory factory = createRdfFactory();

		Rdf''''''Database db = factory.databaseFactory();
		
		Rdf''''''Writer ww = factory.writerFactory();
		
		return ww.doSomethingWith(db);
	  }
	  public Rdf''''''Factory createRdfFactory();

	}

	public class Jena2Client extends Template2Client {
	  public Rdf''''''Factory createRdfFactory() {
		return new Jena''''''Factory();
	  }
	}
Notice: I used a factory-method to choose the factory-class to use (I named it createRdfFactory to avoid confusion with the alternative, RdfFactoryF''''''actory). The following uses just the AbstractFactoryPattern, but is a less-flexible design:

	public class Jena3Client {
	  public Map writeDatabase() {
		Rdf''''''Factory factory = new Jena''''''Factory();

		Rdf''''''Database db = factory.databaseFactory();
		
		Rdf''''''Writer ww = factory.writerFactory();
		
		return ww.doSomethingWith(db);
	  }
	}
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.

Hope that helps! -- JimmyCerra 

''What if Jena2Client is implemented as:''
	public class Jena2Client extends Template2Client {
	  public Rdf''''''Factory createRdf''''''Factory() {
		return new Sesame''''''Factory();
	  }
	}
''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:
	public class My''''''Client extends Template2Client {
	  public Rdf''''''Factory createRdf''''''Factory() {
	    return new Jena''''''Factory();
	  }
	}
Your client could be written with:
	public class Your''''''Client extends Template2Client {
	  public Rdf''''''Factory createRdf''''''Factory() {
	    return new Seseme''''''Factory();
	  }
	}
As you can see, the factory method makes it is easy to switch abstract Rdf''''''Factory 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 FactoryMethod''''''s - as the above example does - they are not limited to them. Alternatives include (but are not limited to) Abstract Factories that use:

* BuilderPattern (builds objects in a series of steps)
* 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

----
See also: AbstractFactory, FactoryMethod, PrototypePattern