Factory Method Design Pattern in C#

Factory Method Design Pattern
Share this

In this article on Design Patterns, I will explain Factory Method Design Pattern in C#. I will demonstrate the concept by creating a sample console application without Factory Method Design Pattern first, highlight the design issues and finally transform the design to a Factory Design Pattern.

Source Code : Complete source can be found on GitHub Repo :


Before diving into details, let’s understand what is Factory Method Design Pattern. It is one of the Gang of Four (GoF) Creational Design Pattern.

Creational Design Pattern focusses on object creation where object creation could result in design complexity or increased complexity of a code base. It hides the object creation logic rather than instantiating the objects directly with new operator.

Factory Method Design Pattern is a creational design pattern which creates objects without exposing the instantiation logic to the client. It refers to the newly created object through a common interface.

Let’s begin by creating two UI controls – Button and RadioButton. Create two concrete classes Button.cs and RadioButton.cs with a Display() method as shown follows:-

Next in the Main() method, create instances of the Button and RadioButton concrete classes and call the Display() method as shown follows.

Output of the above code looks as follows.

Button displayed.
Radio Button displayed.

The program produces the correct output as expected. So, you may think what’s wrong with the above code. Well, there is nothing wrong with the above code. But certainly, there are major design issues which are highlighted as follows.

(1) Object creation is done inside Program class (which I will refer to as the client) multiple times using the new keyword. This overloads the client with object creation activities

(2) All types of UI controls are needed to be known by the client. If there is a need to add a new UI control like CheckBox, it needs to be referenced in the client and the client needs to be complied again

Considering these above-mentioned issues, let’s investigate how Factory Pattern can help to resolve the issues.

Create a new interface IControl as shown follows.

Both the Button and RadioButton classes need to implement this interface IControl as shown follows.

Next create a new class named ButtonFactory.cs with a static method GetButton(int buttonType) returning object type.

GetButton method accepts an integer argument and returns the specific type of object of the concrete classes which is either Button or RadioButton as per user’s choice.

As you can see from the above code snippet, all the object creation logic is now centralized inside the Factory class and this decouples the client from the object creation logic.
Now in the client, let’s call this Factory class method to get the specific concrete class object.

As you can see from the above code snippet, we are able to get an object of the concrete classes which is either Button or RadioButton as per user’s choice. However, the ButtonFactory class returns an object and not a concrete instance. So, a typecasting is again required to convert the object to specific concrete type. It is not a good design as client needs to be aware of the concrete classes and any new addition of concrete class will cause the client to be recompiled.

Let’s improve this Factory Pattern design further. In the ButtonFactory class, change the GetButton method’s return type to be of type IControl instead of object.

Now, in the client which is our Main() method, change the objButton variable’s type to be of IControl instead of object an call the Display() method of the ButtoFactory class  directly instead of creating a new method like Display accepting parameter of type object.

The client which is the Main() method of Program.cs calls GetButton function to display the UI Control. Client only refers to IControl type and factory class ButtonFactory also gives the same type of reference.

Client is completely detached from the concrete classes. When new concrete classes are added as new UI Control like CheckBox, we don’t need to recompile the client.

Output of the above code looks as follows.

Button displayed.
Radio Button displayed.

Class diagram can be seen as follows.

Factory Method Design Pattern Class Diagram

UML Diagram can be seen as follows.

Factory Method Design Pattern UML Diagram

As you can see in the UML diagram and also from the C# code, I have kept the Display() method public in Button and RadioButton classes while the GetButton() method internal in ButtonFactory class. I can make the Display() method also internal in the concrete classes as all the classes belong to the same assembly. However, to display the difference in UML notation between public (+) and internal (~) members.

This concludes the article – Factory Method Design Pattern in C#. I hope you liked this article. If you have any comments, questions or suggestions, please post them in the comments section below this article. I will try to respond at my earliest or somebody else reading the article and your comment will try to respond.

Please like and share this article and subscribe to my blog via email to get regular updates on the latest articles.

Share this

Leave a Reply