Published: 05 Sep 2008
By: Granville Barnett
Download Sample Code

In this part of the design patterns series we will take a look at the factory pattern.

Contents [hide]


The factory pattern is all about delegating the creation of the correct object. In essence the factory will decide what object to create.

Design Patterns Series

  • Part 1 Learn how to design more robust and maintainable code by incorporating design patterns into your software projects.
  • Part 2 This part shows the observer design pattern.
  • Part 3 In this part you will learn about the factory pattern.
  • Part 4 This part of the design patterns covers the singleton pattern.
  • Part 5 In this part of the design patterns series we investigate the command pattern and its uses.
  • Part 6 In this part of the design patterns series we will look at the adapter pattern.
  • Part 7 In this part of the design patterns series we will take a look at the template pattern.
  • In this part of the series we will use a similar theme to that which was used in Part 1 (when we looked at the strategy pattern). The use of car models extends itself particularly well when describing the factory pattern.

    We will cover two variations of the factory pattern. The first will be what is known as a simple factory, the second will be the actual factory pattern. Coverage of the simple factory is purely down to the fact that many people use it in their code, particularly as it is a simple way to delegate object creation.


    The simple factory is not a design pattern.

    The simple factory

    The simple factory is usually represented as a single method. Within that method you have all the required logic to create and return the correct object to the caller.

    Imagine a scenario where you have a series of conditional checks in your code. Each condition will, as part of its body, initialize a variable to the correct type. The correct type is based upon the parameter to the simple factory method, thus the created type differs from parameter to parameter. As an example let us consider that you are in a car factory that can create any car imaginable. All that is required of the customer is to provide the model of the car to create and the automated robots in the factory will do the rest. You need only wait at the end of the production belt for your desired car. The method to create the correct car may look something like the following:

    Listing 1: A simple factory for creating the correct car model object

    In the previous listing Car is an abstract class which only contains a Name property, DB9, and Enzo derive from Car.

    Listing 2: Simple driver program for our simple factory

    We won’t dwell much on this example, the code is attached to this article for further inspection. The method of main interest though is CreateCar. This method is in charge of creating the correct Car object. As Car is an abstract class (could be an interface) we are not coding to a concrete implementation. The result of this is that we encapsulate the creation of the correct Car object in a loosely coupled fashion.

    As we previously mentioned this is not a design pattern. What the simple factory provides is a convenient way to encapsulate object creation for fairly basic scenarios. The approach itself is very straightforward and is a nice build up to the factory pattern. The emphasis here is that we delegate the creation of the correct Car to the CreateCar method. We will see a similar approach in the factory pattern, albeit a little more structured with respect to its design.

    Factory pattern

    A more expansive and indeed what is typically known as the factory pattern is to delegate the creation of the correct object to the appropriate subclass. It will be the subclass that decides what object to create. Before we look at our new design it is important to identify a few roles within this pattern. Typically we have what is known as an abstract creator, this class defines the abstract factory method. The goal of this method is to produce a product, in our example of the simple factory the product would be a Car. A Car being what the factory method returns. The classes that derive from our abstract creator are the classes that produce products, e.g. we might have an AstonMartinFactory that produces products specific to the Aston Martin brand and so on. Such classes are called concrete creators.

    As we have seen with the simple factory approach it is perhaps a little too naïve to model the car based factory on. For a much more life-like design the fully fledged factory pattern is more appropriate. In our design we will have an abstract creator by the name of CarFactory. We will create a few concrete creators, namely AstonMartinFactory, and FordFactory. To make things simpler each factory will be able to give us back either a low, mid, or high end car model that is specific to that manufacturer. All products that our factories give us will derive from the abstract class Car. The models that we use aren’t really that important, but hopefully they will illustrate the pattern well.

    Figure 1: Our factory pattern design

    Our factory pattern design

    There is not much to add to the UML that we haven’t already discussed. To clarify though, all the types that derive from Car are concrete products, Car being the abstract class for all products. CarFactory contains the abstract factory method. The two classes that derive from CarFactory are the concrete creators – FordFactory, and AstonMartinFactory. The purpose of calling the CreateCar method is attaining the correct product object.

    Listing 3: CarFactory.cs

    Listing 4: AstonMartinFactory.cs

    Listing 5: FordFactory.cs

    Listing 6: Range.cs

    Listing 7: Car.cs

    Listing 8: Escort.cs

    Listing 9: Focus.cs

    Listing 10: GT.cs

    Listing 11: DB9.cs

    Listing 12: DBS.cs

    Listing 13: Vantage.cs

    Listing 14: Program.cs

    If we run the project you will see the following output to the console:

    Figure 2: Result of running the program

    Result of running the 


    If you change the factory being used to the AstonMartinFactory and vary the input provided to the CreateCar method you will see that the correct object is created each time. The creation of the correct product is delegated to the correct subclass of CarFactory.


    In this article we have looked at the simple factory, and the factory pattern. The factory pattern is a way to delegate, and encapsulate object creation via subclasses in a loosely coupled fashion. Note that we always used the abstract type’s CarFactory, and Car so that we didn’t code to a concrete type. This keeps our design loosely coupled. Like many design patterns the beauty of the factory pattern lies in its simplicity and maintainability.

    <<  Previous Article Continue reading and see our next or previous articles Next Article >>

    About Granville Barnett

    Sorry, no bio is available

    This author has published 32 articles on DotNetSlackers. View other articles or the complete profile here.

    Other articles in this category

    Introduction to StructureMap
    Have you heard of StructureMap, generally know what it’s for, and want to know how to get started qu...
    DI Patterns: Constructor Injection
    In this article, an excerpt from the book "Dependency Injection in .NET", we will take a detailed lo...
    The Command Pattern
    In this article I will provide a quick refresher on what the command pattern is used for, how it wor...
    TypeMock’s Arrange-Act-Assert
    Brian Mains discusses how to implement the Arrange-Act-Assert pattern in TypeMock.
    Key Process Patterns
    This article, based on chapter 2 of Specification by Example, presents effective patterns for softwa...

    You might also be interested in the following related blog posts

    Learn design patterns from real projects: JBoss case study (Part 1). read more
    Designing a Windows 8 Metro style app starting from an existing Windows Phone app Design Case Study Part 1 read more
    Oredev Wrap-Up read more
    Introducing SharePoint 2010 Training at U2U read more
    The Underground at PDC read more
    12 ASP.NET MVC Best Practices read more
    Screencast Whats new in the Entity Data Model Designer in VS2010 read more
    What needed to be monitored to get better Governance read more
    SharePoint 2010 Workflow read more
    Formatting Text in RadControls for WinForms Q3 2009 read more


    Subject Author Date
    placeholder Decent Article Sean Ludemann 9/12/2008 12:09 PM
    RE: Decent Article Granville Barnett 9/12/2008 12:19 PM

    Please login to rate or to leave a comment.