How to use the Simple Factory Pattern in C#

One of the most common Software Design Pattern you’ll find when developing C# application is the Simple Factory Pattern, which software design pattern which returns an instance of one of several possible classes depending on the type of data provided. It is quite common to return a common parent class and common methods, but each may preform a task differently or optimised for different data or bahviours.

When software developers discuss typical software design patterns they generally talk about the 23 GOF Patterns discussed in the book – Design patterns : elements of reusable object-oriented software – which describes various development techniques and pitfalls in addition to providing twenty-three object-oriented programming design patterns. However the Simple Factory Pattern is not discused within the book!

In this post we will explore the Simple Factory Pattern further to understand when and why to use this pattern in a software development project.
Code available on Github

In software development a Software Design Pattern is a reusable solution to commonly recurring problems. A software design pattern is a description or template used to solve a problem that can be used in many different situations.

In 1994, the so called Gang Of Four (GOF) published their book, Design patterns : elements of reusable object-oriented software, in which they presented a catalog of simple and succinct solutions to commonly occurring design problems.

The book captured 23 Patterns that enabled software architects to create flexible, elegant and ultimately reusable design patterns without having to rediscover or reinvent the design solutions for themselves. It’s a great resource, for those developers who want to learn more about common software design patterns and how to implement them. However, the book doesn’t cover all software design patterns, and it definitely doesn’t cover some of the most frequently found software patterns.

The Simple Factory Pattern, is probably one of the most widely used patterns and at the same time it is also one of the most under used software patterns. I frequently come across scenarios in code bases, when developers have encountered a problem and instead of eleganly handling it, they often pollute function methods with additional lines of cruft logic. Which can often be the source of additional logic bugs or lead to scalability and adaptability issues later on.

Simple Factory Pattern is a Factory class in its simplest form, compared to Factory Method Pattern or Abstract Factory Pattern, is a factory object for creating other objects. In simplelest terms Factory helps to keep all object creation in one place and avoid of spreading new key value across codebase.

The classes a Simple Factory Pattern returns will have the same parent class and methods, but will perform task differently dependent of the type of data supplied.

How the Simple Factory Pattern Works

Let’s take a look at the diagram to get a high-level view of how the Simple Factory Pattern works in C# and .net core. The simple factory design pattern is a form of abstraction, which hides the actual logic of an implementation of an object so the initialization code can focus on usage, rather than the inner workings.

Simple Factory Pattern

In the diagram Manufacture is a base class, and classes Chocolate and MotorVehicle are derived from it, the Manufacture class decides which of the subclasses to return, depending on the arguments provided.

The developer using the Manufacture class doesn’t really care which of the subclasses is returned, because each of them have the same methods but will have different implementations. How the factory class decides which one to return, is entirely up to what data is suuplied. It could be very complex logic, however most often it is very simple logic.



Code Example

To build a Hypothetical sample of a Simple Factory Pattern, consider a typical Firstname and Lastname scenario. If we consider we’re going to build an application that will take a username string input from various applications. However, there is some inconsistency in how the string is supplied. In one application it is passed through as "FirstName LastName" and the other application it is passed through as "LastName, FirstName".

We wouldn’t want to pollute our code base with different string manipulation strategies when we could make use of different classes to handle this scenario based on the input received.

Deciding which version of the name to display can be a simple decision making use of the simple If then statement.

We’ll start by defining a simple class that takes the username as string argument in the constructor and allows you to fetch the split names back.

First, we’ll define a simple base class for the Username, consisting of the basic properties we need.

Derived classes

We can develop two very simple derived classes that implement the abstract class and split the username into two parts in the constructor.  In this example we’ll base the class on the assumption that the username is separated by a space, when we need to use the FirstName first scenario

 

 

In the second class, we’ll base it on the assumption that the name is split by a comma.



Build a Simple Factory Pattern

We’ll build a Simple Factory which simply tests for the existence of comma and then return an instance of one class or the other.



Testing Our Factory Pattern

We can now simply test our factory pattern using xUnit unit testing framework as follows.

As you can see now, when we make a call to GetUserName function we simply pass in the string and the factory method decides which version of the UserName instance to pass back to the application. The developer doesn’t need to concern themselves with any of the string manipulation required. The UserNameFactory simple factory design pattern is a form of abstraction, which hides the actual logic of implementation of an object so the initialization code can focus on usage, rather than the inner workings. provides us the detail we need, all we need to do is pass the name string in and the factory will determine which class to use to format the data.

UserName Simple Factory



Test in isolation

Purists in the Test Driven Development community may argue that the tests above may actually be conceived as Integration Tests, due in part that there are a number of Classes Under Test and the class we have tested has some Cross Cutting Concerns . It is also possible that during a code review it could be suggested that all the classes you create and use should be tested.

We can easily introduce more tests to our project, because we have actually isolated specific logic to classes. Just to illustrate this we can introduce further tests.

These tests should now enable us to further fine tune the logic within our class, in order to cope with further scenarios or business logic.

Summary

That is the fundamental principle of the Simple Factory Pattern, to create an abstraction that decides which of the several possible classes to return. A developer simply calls a method of the class without knowing the implementation detail or which subclass it actually uses to implement the logic.

This approach helps to keep issues of data dependence separated from the classes’ useful methods.

Gary Woodfine

Freelance Full Stack Developer at threenine.co.uk
Helps businesses by improving their technical proficiencies and eliminating waste from the software development pipelines.

A unique background as business owner, marketing, software development and business development ensures that he can offer the optimum business consultancy services across a wide spectrum of business challenges.
π