In software development, design patterns provide a proven solution to common problems. They are not specific to any particular language, but in C#, they are widely used to build scalable, maintainable, and efficient applications. Design patterns help developers avoid reinventing the wheel by providing reusable solutions that follow best practices.
In this guide, we’ll dive into some of the most essential design patterns that every C# developer should know. We’ll cover creational, structural, and behavioral patterns, offering explanations and practical examples for each.
Table of Contents
- What are Design Patterns?
- Creational Patterns
- Singleton Pattern
- Factory Method Pattern
- Abstract Factory Pattern
- Builder Pattern
- Prototype Pattern
- Structural Patterns
- Adapter Pattern
- Decorator Pattern
- Facade Pattern
- Proxy Pattern
- Composite Pattern
- Behavioral Patterns
- Observer Pattern
- Strategy Pattern
- Command Pattern
- State Pattern
- Chain of Responsibility Pattern
- Conclusion
1. What are Design Patterns?
Design patterns are reusable solutions to common software design problems. They provide templates or blueprints for solving issues related to object creation, interaction, and organization. While they do not provide specific code, they offer guidelines on how to implement solutions using best practices.
Design patterns are categorized into three major types:
- Creational Patterns: Focus on the creation of objects in a manner suitable to the situation.
- Structural Patterns: Deal with object composition, defining how to combine objects to form larger structures.
- Behavioral Patterns: Concerned with object collaboration, defining how objects interact with each other.
Using design patterns in C# allows developers to build more organized, flexible, and scalable systems, avoiding pitfalls such as tightly coupled code, duplication, and poor maintainability.
2. Creational Patterns
Creational patterns are concerned with the creation of objects and abstracting the instantiation process. These patterns help make systems independent of how their objects are created.
Singleton Pattern
The Singleton Pattern ensures that a class has only one instance and provides a global point of access to that instance. This is commonly used when managing a shared resource like a database connection or logging system.
Example:
public class Singleton
{
private static Singleton instance = null;
private static readonly object lockObject = new object();
private Singleton() { }
public static Singleton Instance
{
get
{
lock (lockObject)
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
}
public void DoSomething()
{
Console.WriteLine("Singleton instance invoked.");
}
}In this example, the Instance property ensures that only one instance of the class is created, even in a multithreaded environment.
Factory Method Pattern
The Factory Method Pattern defines an interface for creating an object, but allows subclasses to alter the type of objects that will be created. It provides a way to delegate the instantiation logic to child classes.
Example:
public abstract class Creator
{
public abstract IProduct CreateProduct();
}
public class ConcreteCreatorA : Creator
{
public override IProduct CreateProduct()
{
return new ProductA();
}
}
public class ConcreteCreatorB : Creator
{
public override IProduct CreateProduct()
{
return new ProductB();
}
}
public interface IProduct
{
string GetDetails();
}
public class ProductA : IProduct
{
public string GetDetails() => "Product A";
}
public class ProductB : IProduct
{
public string GetDetails() => "Product B";
}In this case, the CreateProduct method is implemented by subclasses that decide which specific product to instantiate. This pattern helps when you need to control the creation of different types of objects.
Abstract Factory Pattern
The Abstract Factory Pattern provides an interface for creating families of related objects without specifying their concrete classes. It is used when a system needs to work with multiple types of related objects that should be created in a consistent manner.
Example:
public interface IGUIFactory
{
IButton CreateButton();
ICheckbox CreateCheckbox();
}
public class WindowsFactory : IGUIFactory
{
public IButton CreateButton() => new WindowsButton();
public ICheckbox CreateCheckbox() => new WindowsCheckbox();
}
public class MacOSFactory : IGUIFactory
{
public IButton CreateButton() => new MacOSButton();
public ICheckbox CreateCheckbox() => new MacOSCheckbox();
}The IGUIFactory interface defines methods to create related objects (button and checkbox), and concrete factory classes implement this interface to create platform-specific objects.
Builder Pattern
The Builder Pattern separates the construction of a complex object from its representation. It allows developers to create complex objects step by step, especially when an object has many optional or configurable attributes.
Example:
public class Car
{
public string Engine { get; set; }
public int Wheels { get; set; }
public bool HasGPS { get; set; }
}
public class CarBuilder
{
private Car car = new Car();
public CarBuilder AddEngine(string engine)
{
car.Engine = engine;
return this;
}
public CarBuilder AddWheels(int number)
{
car.Wheels = number;
return this;
}
public CarBuilder AddGPS()
{
car.HasGPS = true;
return this;
}
public Car Build() => car;
}The CarBuilder allows for a flexible and readable way of building a Car object, especially when there are multiple parameters to configure.
Prototype Pattern
The Prototype Pattern is used to create duplicate objects or clones from an existing object while ensuring that the cloning process is efficient. It’s useful when creating a new object is expensive.
Example:
public abstract class Shape
{
public abstract Shape Clone();
}
public class Circle : Shape
{
public int Radius { get; set; }
public override Shape Clone()
{
return new Circle { Radius = this.Radius };
}
}In this example, the Clone method allows us to create a new Circle object with the same properties as the original.
3. Structural Patterns
Structural patterns focus on the composition of classes and objects. They help ensure that if you need to use several objects together, they will work seamlessly.
Adapter Pattern
The Adapter Pattern converts the interface of a class into another interface that a client expects. It’s commonly used when you want to integrate existing classes into a system with incompatible interfaces.
Example:
public interface ITarget
{
void Request();
}
public class Adaptee
{
public void SpecificRequest() => Console.WriteLine("Specific request");
}
public class Adapter : ITarget
{
private Adaptee _adaptee;
public Adapter(Adaptee adaptee)
{
_adaptee = adaptee;
}
public void Request()
{
_adaptee.SpecificRequest();
}
}The Adapter class allows the Adaptee to be used with the ITarget interface, even though their interfaces are incompatible.
Decorator Pattern
The Decorator Pattern attaches additional responsibilities to an object dynamically, providing a flexible alternative to subclassing for extending functionality.
Example:
public interface ICoffee
{
string GetDescription();
double GetCost();
}
public class SimpleCoffee : ICoffee
{
public string GetDescription() => "Simple coffee";
public double GetCost() => 2.00;
}
public class MilkDecorator : ICoffee
{
private readonly ICoffee _coffee;
public MilkDecorator(ICoffee coffee)
{
_coffee = coffee;
}
public string GetDescription() => _coffee.GetDescription() + ", Milk";
public double GetCost() => _coffee.GetCost() + 0.50;
}Here, the MilkDecorator adds milk functionality to the SimpleCoffee object without altering its structure.
Facade Pattern
The Facade Pattern provides a simplified interface to a complex subsystem. It’s often used when working with complex libraries or APIs to make their usage easier for clients.
Example:
public class Subsystem1
{
public void Operation1() => Console.WriteLine("Subsystem1: Operation1");
}
public class Subsystem2
{
public void Operation2() => Console.WriteLine("Subsystem2: Operation2");
}
public class Facade
{
private readonly Subsystem1 _subsystem1 = new Subsystem1();
private readonly Subsystem2 _subsystem2 = new Subsystem2();
public void PerformOperation()
{
_subsystem1.Operation1();
_subsystem2.Operation2();
}
}By using the Facade class, clients don’t need to interact directly with Subsystem1 and Subsystem2, simplifying their experience.
Proxy Pattern
The Proxy Pattern provides a surrogate or placeholder for another object to control access to it. This is particularly useful when dealing with resource-heavy objects that should be instantiated only when necessary.
Example:
public interface IService
{
void Execute();
}
public class RealService : IService
{
public void Execute() => Console.WriteLine("Executing real service");
}
public
class ProxyService : IService
{
private RealService _realService;
public void Execute()
{
if (_realService == null)
{
_realService = new RealService();
}
_realService.Execute();
}
}The ProxyService acts as a proxy to the RealService, delaying its instantiation until it is actually needed.
Composite Pattern
The Composite Pattern allows you to treat individual objects and compositions of objects uniformly. It’s often used for representing tree structures, such as file systems or UI components.
Example:
public interface IComponent
{
void Operation();
}
public class Leaf : IComponent
{
public void Operation() => Console.WriteLine("Leaf operation");
}
public class Composite : IComponent
{
private readonly List<IComponent> _children = new List<IComponent>();
public void Add(IComponent component)
{
_children.Add(component);
}
public void Operation()
{
foreach (var child in _children)
{
child.Operation();
}
}
}In this pattern, Composite contains Leaf objects, and both implement the same interface. This allows the client to treat leaf and composite objects uniformly.
4. Behavioral Patterns
Behavioral patterns are concerned with the interaction and communication between objects. These patterns help define how objects should communicate with each other while keeping their behavior consistent.
Observer Pattern
The Observer Pattern defines a subscription mechanism for notifying multiple objects (observers) about state changes in a subject. It’s commonly used in event-driven systems.
Example:
public class Subject
{
private readonly List<IObserver> _observers = new List<IObserver>();
public void Attach(IObserver observer)
{
_observers.Add(observer);
}
public void Notify()
{
foreach (var observer in _observers)
{
observer.Update();
}
}
}
public interface IObserver
{
void Update();
}
public class ConcreteObserver : IObserver
{
public void Update() => Console.WriteLine("Observer notified");
}In this example, observers can register themselves with the Subject and are notified when the Subject changes its state.
Strategy Pattern
The Strategy Pattern defines a family of algorithms and encapsulates each one, allowing the algorithm to be changed at runtime. This pattern is useful when you need to switch between different algorithms based on context.
Example:
public interface IStrategy
{
void Execute();
}
public class ConcreteStrategyA : IStrategy
{
public void Execute() => Console.WriteLine("Executing Strategy A");
}
public class ConcreteStrategyB : IStrategy
{
public void Execute() => Console.WriteLine("Executing Strategy B");
}
public class Context
{
private IStrategy _strategy;
public void SetStrategy(IStrategy strategy)
{
_strategy = strategy;
}
public void ExecuteStrategy()
{
_strategy.Execute();
}
}Here, the Context can switch between different strategies (StrategyA or StrategyB) at runtime without altering its structure.
Command Pattern
The Command Pattern encapsulates a request as an object, thereby allowing for parameterization of clients with different requests, queuing of requests, and logging of operations.
Example:
public interface ICommand
{
void Execute();
}
public class LightOnCommand : ICommand
{
public void Execute() => Console.WriteLine("Light is on");
}
public class Invoker
{
private ICommand _command;
public void SetCommand(ICommand command)
{
_command = command;
}
public void Invoke()
{
_command.Execute();
}
}The Invoker can execute commands without knowing the details of the request, making this pattern useful for actions like undoable operations and logging.
State Pattern
The State Pattern allows an object to alter its behavior when its internal state changes. It’s particularly useful for objects that need to exhibit different behavior depending on their state.
Example:
public interface IState
{
void Handle();
}
public class ConcreteStateA : IState
{
public void Handle() => Console.WriteLine("Handling state A");
}
public class Context
{
private IState _state;
public void SetState(IState state)
{
_state = state;
}
public void Request()
{
_state.Handle();
}
}In this example, the Context changes its behavior based on its current state, which is implemented by different state classes.
Chain of Responsibility Pattern
The Chain of Responsibility Pattern allows a request to be passed along a chain of handlers until one handles the request. It’s useful when multiple objects can handle a request, but the handler isn’t determined until runtime.
Example:
public abstract class Handler
{
protected Handler successor;
public void SetSuccessor(Handler successor)
{
this.successor = successor;
}
public abstract void HandleRequest(int request);
}
public class ConcreteHandler1 : Handler
{
public override void HandleRequest(int request)
{
if (request < 10)
{
Console.WriteLine("Handled by Handler 1");
}
else if (successor != null)
{
successor.HandleRequest(request);
}
}
}In this case, the request is passed along the chain of handlers until it is processed by one of them.
5. Conclusion
Design patterns are an essential part of software development in C#. By understanding and mastering these patterns, you can build more maintainable, scalable, and flexible applications. Patterns like Singleton, Factory Method, Observer, and Strategy are commonly used across various projects, and knowing when and how to apply them is crucial for writing clean and efficient code.
Whether you’re developing enterprise applications, web services, or desktop software, these design patterns will help you avoid common pitfalls and write more robust solutions. By integrating these patterns into your C# projects, you’ll be better equipped to tackle complex architectural challenges with ease.
