When should the factory pattern be used?

Question

Just as the title asks, when should a trigger in your head go off signifying "Aha! I should use the factory pattern here!"? I find these moments will occur with many other design patterns, but never do I stop myself and think about this pattern.

Answer 1

Factories are used a lot in localisation, where you have a screen with different layouts, prompts, and look/feel for each market. You get the screen Factory to create a screen based on your language, and it creates the appropriate subclass based on its parameter.

Answer 2

The factory pattern is best employed in situations where you want to encapsulate the instantiation of a group of objects inside a method.

In other words, if you have a group of objects that all inherit from the same base class or all implement the same interface that would be an instance where you would want to use the factory pattern (that would be the "pattern" you would look for).

Answer 3

I can think of two specific cases that I think of the factory pattern:

• When the constructor has logic in it.
• When I don't want the application to worry about what type gets instantiated (eg, I have an abstract base class or interface that I am returning).

Answer 4

Quoted from GoF:

Use the Factory Method pattern when

• a class can't anticipate the class of objects it must create
• a class wants its subclasses to specify the object it creates
• classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

I highly recommend the GoF book. It has a section on the applicability of each of the 23 patterns it covers.

Answer 5

Whenever you find yourself with code that looks something like this, you should probably be using a factory:

IFoo obj;
if ( someCondition ) {
   obj = new RegularFoo();
} else if ( otherCondition ) {
   obj = new SpecialFoo();
} else {
   obj = new DefaultFoo();
}

Answer 6

Are you talking about Factory Method or Abstract Factory?

The basic problem that both solve is letting clients specify the exact class that framework code constructs. For example, if you provide an interface, that clients can implement, and then in your code have something like:

IMyInterface x = new ConcreteClass();

There is no way for clients to change the exact class that was created without access to that code.

A Factory Method is a virtual method that constructs a concrete class of a specific interface. Clients to your code can provide an object that overrides that method to choose the class they want you to create. It might look like this in your code:

IMyInterface x = factory.Create();

factory was passed in by the client, and implements an interface that contains Create() -- they can decide the exact class.

Abstract Factory should be used if you have hierarchies of related objects and need to be able to write code that only talks to the base interfaces. Abstract Factory contains multiple Factory Methods that create a specific concrete object from each hierarchy.

In the Design Patterns book by the Gang of Four, they give an example of a maze with rooms, walls and doors. Client code might look like this:

IRoom r = mazeFactory.CreateRoom();
IWall nw = mazeFactory.CreateWall();
IWall sw = mazeFactory.CreateWall();
IWall ew = mazeFactory.CreateWall();
IWall ww = mazeFactory.CreateWall();
r.AddNorthWall(nw);
r.AddSouthWall(sw);
r.AddEastWall(ew);
r.AddWestWall(ww);

(and so on)

The exact concrete walls, rooms, doors can be decided by the implementor of mazeFactory, which would implement an interface that you provide (IMazeFactory).

So, if you are providing interfaces or abstract classes, that you expect other people to implement and provide -- then factories are a way for them to also provide a way for your code to construct their concrete classes when you need them.