Creational Design Patterns

Introduction

Design patterns are reusable solutions to common problems in software design. Instead of solving the same problem repeatedly, developers can use proven design techniques to build maintainable and scalable systems.

One of the most influential books in software engineering is Design Patterns: Elements of Reusable Object-Oriented Software, written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

These authors are commonly known as the Gang of Four (GoF) and introduced 23 classic design patterns that help developers design flexible and maintainable software systems.

In this article, we will understand Creational Design Patterns in C#, why they are needed, and how they improve object creation in real-world applications.

Problem without Creational Design Pattern

Let's take an example of below code snippet.

var payment = new CreditCardPayment();
var logger = new FileLogger();
var config = new AppConfig();

When objects are created directly like this, several design problems appear:

Tight Coupling
The class is tightly coupled with concrete implementations like CreditCardPayment and FileLogger. If we want to change them (eg. PaypalPayment or DatabaseLogger), we must modify the existing code.
Hard to Test
Unit testing becomes difficult because dependencies are created inside the class. It is hard to replace them with mock or fake implementations during testing.
Difficult to Change Implementation
If the application grows and we want to switch to a different payment method or logging mechanism, we must change the code in many places.
Violates SOLID Principles
This approach violates important design principles such as:

Dependency Inversion Principle (DIP) – depending on concrete classes instead of abstractions.

Single Responsibility Principle (SRP) – the class is responsible for both business logic and dependency creation.

The fundamental idea is separating the “what” from the “how”.

Types of Creational Design Patterns

Singleton Pattern

The Singleton pattern is a creational design pattern that ensures a class has only one instance throughout the application’s lifetime and that that instance is available for access from anywhere.

While building the software, we often encounter scenarios where multiple instances of a class could lead to problems like inconsistent state/data, resource conflicts, or inefficient resource utilization. Singleton pattern solves this by ensuring a class has only one instance, and that will be used globally across a program. It is commonly used for shared resources such as configuration settings, logging services, or database connections.

Further reading on Singleton Pattern: Singleton Pattern in .NET

Factory Method Pattern

The Factory Pattern is a creational design pattern that provides a centralized place to creating an objects without exposing the object creation logic to the client.

The client requests a factory for an object, and the factory decides which concrete class to instantiate. Instead of using new keyword to create a object, object creation will be delegated to the factory.

When the system grows, one of the first design problems we face is object creation. Tight coupling between object creation and object usage makes code hard to extend, test, and maintain. That’s where the Factory Pattern becomes extremely useful.

Further reading on Factory Method Pattern: Factory Method Pattern in C#

Abstract Factory Pattern

Abstract Factory Pattern is a creational design pattern that provides an interface for creating multiple or dependent objects without specifying their concrete classes.

It basically has:

An abstract factory interface that defines a set of methods for creating related objects.
Multiple concrete factory classes that implement this interface to create specific variants of those related objects.
A set of abstract interfaces or type definitions that define the contracts for the objects being created.
Multiple concrete implementations of those abstract types, organized into groups.

The Abstract Factory Pattern allows you to create related objects in a consistent way without tightly coupling code to specific concrete classes.

Further reading on Abstract Factory Pattern: Abstract Factory Pattern in .NET

Builder Pattern

In software development, sometimes we need to create complex objects that contain multiple fields and configuration options. Even if we try to build such objects using a constructor, we may end up having too many parameters, which obviously makes the code hard to read and difficult to maintain.

This is where Builder Design Pattern becomes useful.

Builder Pattern is a creational design pattern that helps to construct the complex objects step by step. It separates the object construction process from its representation and allows the same construction process to create different representations.

Further reading on Builder Pattern: Builder Pattern in C#

Prototype Pattern

The Prototype Pattern is a creational design pattern that allows objects to be copied or cloned rather than created using constructors. Rather than instantiating a new object, manually setting all the properties, the system duplicates an existing object(prototype) and modifies it as needed.

In many real-world system, object creation is not always simple. Some objects might require complex initialization logic like Database lookups, Configuration loading, and Resource allocation, setting many default properties, when such objects are created frequently, constructing them from scratch might not be efficient.

Further reading on Prototype Pattern: Prototype Pattern in C#