Factory Method Pattern – Why Subclass Instead of Composite?

compositiondesign-patternsfactory-methodinheritance

I'm currently learning about design patterns. I learned about the Factory Method pattern.

This pattern means that in order to implement a factory to create objects, one should subclass the class that needs these objects, and have the subclass create them. This way the superclass only works with more abstract references instead of the concrete implementations the subclass generates, which creates a loosely coupled design.

This usually means the superclass becomes abstract, since it's createObject() method must be abstract so that the subclass containing the factory method will have to implement this method.

Like any factory pattern, this pattern encapsulates the creation of the concrete object, and allows the client to work with a higher level of abstraction. But this specific pattern is built on inheritance.

What I don't understand is – Why would anybody go through all the trouble of subclassing the class that needs a factory and making it abstract? Composition is so much better for this purpose in any way.

It makes much more sense to create an abstract class or an interface called Factory. It would declare one method: createObject(). We create concrete implementations of it for different purposes (WeaponFactory, TitleFactory..) Then, we give the client a Factory member instance factory. This reference is set to whatever concrete Factory is needed at runtime, and the client can simply use factory's createObject() when needed (without having to know what concrete implementation factory is holding).

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.

The simple composition-based design I described is better in any way – I think.

Do you agree? Could you explain why anybody would use the Factory Method Pattern I described?

Best Answer

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.

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 vs Factory design pattern

The former one is called a violation of the single responsibility principle :) Your User class shouldn't know or care about the database. It is an anti-pattern, if anything.

There should be only one reason to change the User class - and it is that the concept of user within your application may change.

Implementing LoadUserById on the User class means that you'd have to rewrite that class for totally unrelated reasons - such as switching from MySQL to PostgreSQL, for example, which has nothing to do whatsoever with the user as such. Such implementation details should be detached, externalized.

The latter one is more of a Repository pattern than Factory, I believe. UserRepository could be a quite reasonable name for such a class.

Note that the role of a Factory is to create objects, especially whenever this task is complex and involves some advanced logic that you want to keep in one place.

Retrieving data from the database is a different responsibility. It's not about creating an object in itself - the real goal is obtaining data for that object (or "hydrating" it, as some insist).

Best Answer

Related Solutions

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

Factory method vs Factory design pattern

Related Topic