I'm surprised you didn't include the Builder pattern in the bunch.
Design Patterns: Elements of Reusable Software includes some very concise summaries in the cover that may help:
Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.Builder: Separate the construction of a complex object from its representation so that the same construction process can create different representations.Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses. I never understood why the order of these patterns isn't reversed from simplest to most complex.
You may want to have a look over
Creational Patterns: Creating Objects in an OO System. It makes the point that "JDBC (
Java database connectivity) uses the Factory Method pattern in many of its interfaces. You can use another
JDBC driver as long as the correct driver is loaded." I guess JDBC cannot completely be implemented as an Abstract Factory because implmentation details of the RDBMS must still be known to the "client" to use the database effectively. Note also that the "Abstract Factory is often implemented with factory methods." (GOF p.116).
The Builder is usually used to build Composites, e.g. you give a configuration
string to the builder and it produces an object that contains the necessary parts - or you use the builder to add one part at a time (it knows how to "attach" them) and then extract the finished product. The
abstract builder is more interesting because it can return any sub-type of the class or interface - whatever is necessary to get the job done.
The concrete factories in the abstract factory pattern are usually responsible for returning instances of all the different sub-types of the classes/interfaces that the client uses; a Builder is typically only responsible returning one object. When using the abstract factory pattern you usually implement at least two concrete factories, one concrete factory for each family of subtypes that the client could be using. The client would typically only be using the subtypes from one single family (concrete factory) at a time - usually the subtypes from the different families (concrete factories) don't mix. See
Hibernate - Generic Data Access Objects for an example of the use of abstract and concrete factories. HibernateDAOFactory is shown as the only concrete implementation of the abstract DAOFactory; however the idea is that you can code other DAOFactory implementations like the JDBC family (JDBCDAOFactory,ItemDAOJDBC,CategoryDAOJDBC) or JDO family (JDODAOFactory,ItemDAOJDO,CategoryDAOJDO). Meanwhile the client would only use (DAOFactory,ItemDAO,CategoryDAO) - while concrete factory loaded at runtime could be configured in a properties file.
Or you use different concrete factories at the same time that produce DAOs that can be used tranparently to unify the processing over different sources of data (different schemas, different databases, etc.).
Note also (Cade p.60): The family of related products is designed to be used together***, and you must enforce this constraint. This is the key point to the pattern, otherwise you could use a Factory Method.
***Family 1: (ConcreteFactory1, ProductA1, ProductB1) vs. Family 2: (ConcreteFactory2, ProductA2, ProductB2)
See also
Java GoF Creational Design Patterns