Hi all, I'm going through the GoF patterns chapter. In my work experience I have used sometimes the Factory pattern but there I have found a specialized version of this pattern called Abstract Factory. I have basically understood how it works but if I were asked at the exam what's the scenario when it's best suited one instead of the other....well I would be in troubles..... can anybody shed some light on it ? Thanks a lot Francesco
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)
Well it is kind of the difference of another level of indirection, sort of.
The Factory Method is a Factory that has a "newInstance()" method, and the Abstract Factory is a Factory that isn't implemented, but the subclasses implement it, so your calling client doesn't really know what type of Factory it is getting. Basically you are providing a Factory interface, but not the implementation, that is reserved for the subclasses, which in terms of GOF is a "Family of related or dependent objects without specifying their concrete classes.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).