Questions regarding the Factory pattern

Question

Many people say they are using factory pattern in their project. But when i actually see their implementation it looks totally different from definition what i have read in head first book. In the book they have described two kind of factory pattern i.e

Factory Method:- A class specifies its sub-classes to specify which objects to create based on some parameter. So we expect here some abstract method in base class whihich will be implemented by child class and pupose of that will be to create some object

Abstract Factory:- Provides an factory (in form of interface or abstract factory)for creating families of related or dependent objects without specifying their concrete classes.

I have a question here on what do they mean by family of dependent or related objects. Lets refer to http://www.apwebco.com/gofpatterns/creational/AbstractFactory.html. As per my understanding it means that in FinancialToolsFactory (in the link) is able to create TaxProcessor which is a family of products where actuall concreate products are CanadaTaxProcessor and EuropeTaxProcessor . So here we will have n number of concrete factories(in this case CanadaFinancialToolsFactory and EuropeFinancialToolsFactory) which will be extending/implementing abstract factory in this case FinancialToolsFactory.

Please let me know if above understanding is correct as i think its the crux of Factory pattern.

Second question:

What people are doing on the name of factory pattern is below:

public class MyFactory
{
    public static <T> T getObject(Class<T> cls)
    {
        if (cls == null)
        {
            throw new IllegalArgumentException("Invalid className");
        }

        T daoObject = (T)map.get(cls);

        if (daoObject == null)
        {
            daoObject = loadObject(cls);
        }

        return daoObject;
    }
}

They are just passing class like Example.class from main method and getting the object instance for that specific class. Now if we go by actual concept of factory pattern which is described in beginning(from head first book) and other websites it does not follow any of the two factory patterns. To me it looks like a utility class where we are passing the class and getting the object instance. Please let me know if you folks agree with this?

Answer 1

Your understanding of the Factory Method and Abstract Factory patterns is correct.

When people create classes whose responsibility is solely to create other objects, they naturally tend to name them Factory. That in itself isn't unreasonable. The problem is that there is no Factory pattern.

Confusion arises here for two reasons:

• Some developers just want to throw in another pattern and claim that they're using the "Factory Pattern," referring to the object that creates others

• Developers learning about design patterns see that a class is called a Factory, regardless of whether a pattern is implemented, and assume it must be a Factory Method or Abstract Factory. This is confusing because you're then trying to figure out which one it is, calling into question your own understanding of the real patterns.

Remember that not only are design patterns solutions to commonly encountered problems, but that they serve to establish a language for discussing design. In this case, the design language you expect is not what the developer actually used. What they are doing is only wrong if they say they are using a specific design pattern.

Answer 2

what do they mean by family of dependent or related objects

Using an example from Design Patterns by the Gang of Four:

• AbstractFactory (WidgetFactory)
• ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
• AbstractProduct (Window, ScrollBar)
• ConcreteProduct (MotifWindow, MotifScrollBar, PMWindow, PMScrollBar)

public abstract class WidgetFactory {...}

public class MotifWidgetFactory extends WidgetFactory {...}

public class PMWidgetFactory extends WidgetFactory {...}

Let's start with the MotifWidgetFactory. It will produce a family of concrete products that extend or implement the abstract products. Since they are all built by the same factory, they play nice together. You cannot make a PMScrollBar work with a MotifWindow.

What people are doing on the name of factory pattern is below...it looks like a utility class where we are passing the class and getting the object instance.

Your example is a factory in that it produces an object. In this case, retrieving a singleton from a Map. It does not follow the "Factory Method" or "Abstract Factory" patterns and is therefore only a factory in name.