Design patterns in the test of time: Factory Method

Design patterns in the test of time: Factory Method:

Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.

More on this pattern.

Here is some sample code:

   1: public class MazeGame {

   2:   public MazeGame() {

   3:      Room room1 = MakeRoom();

   4:      Room room2 = MakeRoom();

   5:      room1.Connect(room2);

   6:      AddRoom(room1);

   7:      AddRoom(room2);

   8:   }

   9:  

  10:   protected virtual Room MakeRoom() {

  11:      return new OrdinaryRoom();

  12:   }

  13: }

This pattern is quite useful, and is in fairly moderate use. For example, you can take a look at WebClient.GetWebRequest, which is an exact implementation of this pattern. I like this pattern because this allows me to keep the Open Closed Principle, I don’t need to modify the class, I can just inherit and override it to change things.

Still, this is the class method. I like to mix things up a bit and not use a virtual method, instead, I do things like this:

   1: public class MazeGame {

   2:    public Func<Room> MakeRoom = () => new OrdinaryRoom();

   3: }

This allows me change how we are creating the room without even having to create a new subclass. In fact, it allows me to change this per instance.

I make quite a heavy use of this in RavenDB, for example. The DocumentConventions class is basically built of nothing else.

Recommendation: Go for the lightweight Factory Delegate approach. As with all patterns, use with caution and watch for overuse & abuse. In particular, if you need to manage state between multiple delegate, fall back to the overriding approach, because you can keep the state in the subclass.

DIGITAL JUICE