Design Patterns – Factory Method vs. Factory Method Pattern

design-patternsfactory-method

I am currently studying design patterns from the book (which, although I didn't try anything else, I find excellent) Head First Design Patterns.

I'm confused about two concepts: The Factory Method, and the Factory Method Design Pattern.

I was trying to understand what each one means, and I came to some conclusion. I'd like to know if my definitions are exact.

The Factory Method is a method that is meant to do one thing: Create an object of a specific supertype and return it. It may or may not take a parameter, and may or may not 'decide' using if statements what kind of concrete object to create.

For example, this is a factory method:

public Hat createHat(String hatColor){

    Hat hat;

    if (hatColor.equals("red")) hat = new RedHat();
    else if (hatColor.equals("blue")) hat = new BlueHat();
    else if (hatColor.equals("green")) hat = new GreenHat();
    else hat = new DefaultHat();

    return hat;

}

The Factory Method Design Pattern is named after the Factory Method.

This pattern provides a specific way to encapsulate object creation from the client.

It works like so: The pattern is a system of two classes, the Creator and the ConcreteCreator. The Creator is an abstract class, and the ConcreteCreator is a subclass of that class.

The job of the ConcreteCreator – create an object and return it using a factory method. It only has to contain this one method.

The job of the Creator – manipulate and use the object received from it's subclass, the ConcreteCreator, and usually return it to the client.

It is done like so:

The Creator contains an abstract method, it's signature something like SupertypeObject createObject(). Whenever it needs an object of type SupertypeObject, it calls createObject().

Thing is, createObject() is as I said abstract. It's the ConcreteCreator's job to implement this method.

This way, the implementation of createObject() is hidden from the Creator. It doesn't know what concrete object it gets, but it knows for sure that it's of type SypertypeObject.

This way, a client can use the Creator object to create objects of some supertype, but the concrete objects created will depend on the subclass. Thus declaring ShoeFactory factory = new CaliforniaStyleShoesFactory(), will make the factory produce california style shoes, while ShoeFactory factory = new NYStyleShoesFactory() will make the factory produce NY style shoes. Since the implementation of creating the concrete objects depends on the ConcreteCreator.

Code to demonstrate:

Class Client(){

    public static void main(String[] args){

        ShoeFactory factory;
        Shoe shoe;

        factory = new NYStyleShoeFactory();
        shoe = factory.makeShoe();
        System.out.println(shoe.getDescription()); // "A NY style shoe".

        // ShoeFactory's makeShoe() invokes createShoe() in the subclass, receives a Shoe
        // (doesn't know the concrete type of the Shoe. Depends on the subclass) and
        // does manipulations on it.
        // Returns the Shoe to the client.

        factory = new CaliforniaStyleShoeFactory():
        shoe = factory.makeShoe();
        System.out.println(shoe.getDescription()); // "A California style shoe".

}

}

Is my understanding of the two concepts accurate? Thanks

Best Answer

Yes, you are right.

The pattern is called like that because it describes a known, well accepted solution using a factory method.

The pattern could have been named "XXXX". That doesn't matter.

Regarding @pdr's comment about what you describe being really an "Abstract Factory", the following images clarify the difference, Factory Method is exactly what you describe:

enter image description here

The images are taken from this PDF taken from this site. It was maded by a software engineer by the name of Jason McDonald.

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