Client vs Creator in Factory Method and Abstract Factory patterns

design-patternsfactory-method

This page descibes one important difference between Factory Method and Abstract Factory:

http://architects.dzone.com/articles/factory-method-vs-abstract

The difference, according to this page, is that in Factory Method pattern the Creator (i.e. the entity creating new objects) and the Client (i.e. the entity using the Creator) are the same class. More precisely, this pattern only defines a method, so the rest of the class is the Client. In Abstract Factory however, the Creator and the Client are separate classes. The Creator's only purpose is to create objects so only a separate class can be the Client.

Is this distinction correct? If so, why can't the Creator method in the Factory Method be put in a separate class? Would it create any problems? Similarly, why can't the Creator class in the Abstract Factory be the same class as the Client? Would this create any problems?

Update:

Just as a side note: it's SHOCKING to me too see that when I ask about such well known and (what should be) well defined design patterns I get actually contradictory answers. And it's not just this thread – the more and more I ask people (or search online resources) about the basic design patterns the more I start to think that people don't actually TRULY understand them even though they're using them on a daily basis and they believe they understand them.

Best Answer

Your distinction is not generally correct. For example, the Abstract Factory Pattern uses the Factory Method Pattern. In the Factory Method Pattern, the classes using and providing the factory method need not be the same class.

An Abstract Factory class has object creation as its sole concern. If an abstract factory instance were its own client, this would be a violation of the Single-Responsibility principle.

Below, you'll find a discussion of factory methods, the Factory Method Pattern, the Abstract Factory Pattern, and comparisons between them and other patterns.

Factories or Simple Factories or Factory Methods

A factory is any function that is used to create some data structure. In OOP languages, constructors are often special factory methods that can't be used freely (e.g. you often can't explicitly return something). By wrapping construction in an ordinary method, we can add validation, preprocessing, or further initialization code, and can return objects of different types depending on context. By using factory methods, users are insulated from the specifics of object construction – if we want to switch the type of some object, we only have to change the code inside the factory, and not all the code using that factory.

Simple factories are not a Go4 pattern, but form the basis of many patterns such as the Factory Method Pattern, Abstract Factory Pattern, and the Builder Pattern.

Factory Method Pattern

In the Factory Method Pattern, we have a class that contains an overridable factory method. Subclasses are encouraged to override this method to change the type of the returned object. Pseudocode:

interface Product { … }
class DefaultProduct implements Product { … }
class SpiffyProduct  implements Product { … }

class Creator {
  virtual Product create() { return new DefaultProduct() }
}

class OtherCreator extends Creator {
  override Product create() { return new SpiffyProduct() }
}

// client code:
Creator c = ...;
Product = c.create();

Note that Creator::create is a factory method/simple factory. However, the identifying property of the Factory Method Pattern is the usage of inheritance to change the factory method.

The advantage of the Factory Method Pattern is that in order to change the factory method used in client code, we only have to change the line where the Creator c is obtained/created. This flexibility allows the Factory Method Pattern to be used for simple Dependency Injection tasks.

Variations

If we use the Factory Method Pattern and the client is in the same class as the factory method, then this can also be described as the Strategy Pattern applied as a creational pattern.

The root Creator class need not be instantiable, or provide some default product. Instead, it could be abstract or an interface.

One object can reasonably implement the Factory Method Pattern multiple times for different Products. If object creation is the main purpose of the creator and the different products are related, this is probably better described as the Abstract Factory Pattern.

The Factory Method Pattern is usually used as a helper in order to achieve that object's main concern (e.g. when used in combination with the Strategy Pattern). If the factory method is the only method of a class implementing the Factory Method Pattern, this can also be viewed as an example of the Command Pattern.

Abstract Factory Pattern

The Abstract Factory Pattern uses the Factory Method Pattern to create a palette of related objects. Or: the abstract factory instance is that palette.

While the Factory Method Pattern is often used as a helper to do something else, the main concern of a factory object in the Abstract Factory Pattern is always object creation. As such, the client is always supposed to be a different class, although an abstract factory could also use itself, e.g. to assemble a composite object.

Related Solutions

Factory Pattern vs Abstract Factory – What Is the Difference Between the Factory Pattern and Abstract Factory?

The Factory Method is usually categorised by a switch statement where each case returns a different class, using the same root interface so that the calling code never needs to make decisions about the implementation.

Think of a credit card validator factory which returns a different validator for each card type.

public ICardValidator GetCardValidator (string cardType)
{
    switch (cardType.ToLower())
    {
        case "visa":
            return new VisaCardValidator();
        case "mastercard":
        case "ecmc":
            return new MastercardValidator();
        default:
            throw new CreditCardTypeException("Do not recognise this type");
    }
}

The Abstract Factory is where you have multiple concrete factory classes (not Factory Methods) derived from one interface which may return many different types from different methods.

Think of a chess game manager with a different class for each set of variant rules.

public class StandardChessRulesFactory : IChessRulesFactory
{
    public IBoardMapper GetBoardMapper()
    {
        return new StandardChessBoardMapper();
    }

    public IKingMover GetKingMover()
    {
        return new StandardChessKingMover();
    }

    public IMoveClock GetMoveClock()
    {
        return new StandardMoveClock();
    }
}

public class HexagonalChessRulesFactory : IChessRulesFactory
{
    public IBoardMapper GetBoardMapper()
    {
        return new HexagonalChessBoardMapper();
    }

    public IKingMover GetKingMover()
    {
        return new HexagonalChessKingMover();
    }

    public IMoveClock GetMoveClock()
    {
        return new StandardMoveClock();
    }
}

public class SpeedChessRulesFactory : IChessRulesFactory
{
    public IBoardMapper GetBoardMapper()
    {
        return new StandardChessBoardMapper();
    }

    public IKingMover GetKingMover()
    {
        return new StandardChessKingMover();
    }

    public IMoveClock GetMoveClock()
    {
        return new SpeedChessMoveClock();
    }
}

An Abstract Factory, much like a Strategy, is often selected using a Factory Method, but it isn't necessary to combine them so it is its own pattern.

Factory Method Pattern – Why Subclass Instead of Composite?

The Design Patterns book is descriptive, not prescriptive; it describes the patterns the GoF have observed in the wild; patterns that solve problems.

Some problems can be solved in more than one way.

The alternative you describe is also my preferred approach, but it's also described in the book: it's a combination of the Abstract Factory and Strategy patterns. You use an Abstract Factory as a Strategy.

I don't understand why one would go through the trouble of subclassing a class and making it abstract just for the benefit of allowing it to use a factory in a loosely-coupled manner.

For the exact same reason that you would combine Abstract Factory and Strategy. However, the best solution partly depends on your language.

If, for example, you were programming in Eiffel, Factory Method would probably be easier, because Eiffel has multiple inheritance, but (IIRC) no interfaces.

Also, if you're using a language where you can create a derived value on the spot (such as Java or F#), Factory Method might actually be easier than the Abstract Factory/Strategy combo.