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
Enzo derive from
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.
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 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
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
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 –
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
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
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
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.
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...
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).
Designing a Windows 8 Metro style app starting from an existing Windows Phone app Design Case Study Part 1
Introducing SharePoint 2010 Training at U2U
The Underground at PDC
12 ASP.NET MVC Best Practices
Screencast Whats new in the Entity Data Model Designer in VS2010
What needed to be monitored to get better Governance
SharePoint 2010 Workflow
Formatting Text in RadControls for WinForms Q3 2009
Please login to rate or to leave a comment.