Design Patterns Simplified: Learn the Fundamentals of Design Patterns using C#

// Model
class Product
{
    public string Name { get; set; }
    public double Price { get; set; }
}

// View
class ProductView
{
    public void Display(Product product)
    {
        Console.WriteLine("Product: " + product.Name);
        Console.WriteLine("Price: " + product.Price);
    }
}

// Controller
class ProductController
{
    private Product model;
    private ProductView view;

    public ProductController(Product model, ProductView view)
    {
        this.model = model;
        this.view = view;
    }

    public void UpdateView()
    {
        view.Display(model);
    }

    public void SetProductName(string name)
    {
        model.Name = name;
    }

    public void SetProductPrice(double price)
    {
        model.Price = price;
    }
}

class Singleton
{
    private static Singleton _instance;
    private static readonly object _lock = new object();

    private Singleton()
    {
        // Initialize any resources here
    }

    public static Singleton GetInstance()
    {
        if (_instance == null)
        {
            lock (_lock)
            {
                if (_instance == null)
                {
                    _instance = new Singleton();
                }
            }
        }

        return _instance;
    }

    // Other methods
}

interface IProduct
{
    void Display();
}

class ProductA : IProduct
{
    public void Display()
    {
        Console.WriteLine("This is Product A");
    }
}

class ProductB : IProduct
{
    public void Display()
    {
        Console.WriteLine("This is Product B");
    }
}

class ProductFactory
{
    public static IProduct CreateProduct(string productType)
    {
        switch (productType)
        {
            case "A":
                return new ProductA();
            case "B":
                return new ProductB();
            default:
                throw new ArgumentException("Invalid product type", nameof(productType));
        }
    }
}

interface IObserver
{
    void Update(object sender, EventArgs e);
}

interface ISubject
{
    void Attach(IObserver observer);
    void Detach(IObserver observer);
    void Notify();
}

class ObserverA : IObserver
{
    public void Update(object sender, EventArgs e)
    {
        Console.WriteLine("ObserverA received update");
    }
}

class ObserverB : IObserver
{
    public void Update(object sender, EventArgs e)
    {
        Console.WriteLine("ObserverB received update");
    }
}

class Subject : ISubject
{
    private List<IObserver> _observers = new List<IObserver>();

    public void Attach(IObserver observer)
    {
        _observers.Add(observer);
    }

    public void Detach(IObserver observer)
    {
        _observers.Remove(observer);
    }

    public void Notify()
    {
        foreach (var observer in _observers)
        {
            observer.Update(this, EventArgs.Empty);
        }
    }
}

interface ICommand
{
    void Execute();
}

class Calculator
{
    public int Result { get; set; }

    public void Add(int value)
    {
        Result += value;
    }

    public void Subtract(int value)
    {
        Result -= value;
    }
}

class AddCommand : ICommand
{
    private Calculator _calculator;
    private int _value;

    public AddCommand(Calculator calculator, int value)
    {
        _calculator = calculator;
        _value = value;
    }

    public void Execute()
    {
        _calculator.Add(_value);
    }
}

class SubtractCommand : ICommand
{
    private Calculator _calculator;
    private int _value;

    public SubtractCommand(Calculator calculator, int value)
    {
        _calculator = calculator;
        _value = value;
    }

    public void Execute()
    {
        _calculator.Subtract(_value);
    }
}

In this example, we have an ICommand interface that defines the Execute method that commands should implement and two classes, AddCommand and SubtractCommand, that implement the ICommand interface. In addition, the Calculator class has methods to add and subtract integers and is used by the command classes.

The AddCommand and SubtractCommand classes have a reference to the Calculator class and an integer value. When the Execute method is called, it performs the corresponding operation on the calculator.

The client code can create instances of Calculator, AddCommand, and SubtractCommand, and execute them whenever needed. This way, the command pattern allows you to encapsulate a request as an object, separate the command execution from the command's sender and Receiver, and allow for the undo and redo operations. Additionally, it will enable the system to be independent of how objects are created, composed, and represented.

Learn more here, Command Design Pattern in C# (c-sharpcorner.com).

12. What is the Decorator pattern, and when is it used?

The Decorator pattern is a design pattern that allows new behavior to be added to existing objects without altering their class. It is used to add responsibilities to individual objects dynamically and transparently without affecting other objects.

The Decorator pattern defines a decorator class that implements the same interface as the object it decorates and holds a reference to the object. The decorator class can add new behavior to the object by implementing the same interface and forwarding requests to the object it decorates.

The Decorator pattern is often used when an object needs additional behavior at runtime, and it should be possible to add or remove the behavior without affecting other objects. Some common examples of when the Decorator pattern is used include:

• When you want to add behavior to individual objects but not to an entire class.
• When you want to add behavior to objects at runtime.
• When you want to add behavior to an existing third-party class.

The Decorator pattern promotes code reuse and allows new behavior to be added to existing objects transparently without affecting other objects. It also allows you to add or remove behavior at runtime, which makes the system more flexible and easier to extend. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

Here's an example of the Decorator pattern implemented in C#:

interface IComponent
{
    void Operation();
}

class ConcreteComponent : IComponent
{
    public void Operation()
    {
        Console.WriteLine("ConcreteComponent operation");
    }
}

abstract class Decorator : IComponent
{
    protected IComponent _component;

    public Decorator(IComponent component)
    {
        _component = component;
    }

    public virtual void Operation()
    {
        _component.Operation();
    }
}

class ConcreteDecoratorA : Decorator
{
    public ConcreteDecoratorA(IComponent component) : base(component) { }

    public override void Operation()
    {
        base.Operation();
        Console.WriteLine("ConcreteDecoratorA operation");
    }
}

class ConcreteDecoratorB : Decorator
{
    public ConcreteDecoratorB(IComponent component) : base(component) { }

    public override void Operation()
    {
        base.Operation();
        Console.WriteLine("ConcreteDecoratorB operation");
    }
}

In this example, we have an IComponent interface that defines the Operation method that components should implement and a concrete class ConcreteComponent that implements this interface. The Decorator class is an abstract class that also implements the IComponent interface and has a reference to an IComponent object. It also defines a virtual Operation method that calls.

Learn more here, Decorator Pattern in C# (c-sharpcorner.com).

13. What is the Facade pattern, and when is it used?

The Facade pattern is a design pattern that provides a simplified interface to a complex system. It is used to hide the complexity of a system behind a single, simplified interface, making it easier to use and understand.

The Facade pattern defines a facade class that provides a simplified interface to a complex system. The facade class encapsulates the system's complexity and provides clients with a simplified, easy-to-use interface. It also forwards client requests to the appropriate objects within the system and maps the responses back to the clients.

The Facade pattern is often used when a system is complex and difficult to understand and needs to be simpler and more manageable. Some common examples of when the Facade pattern is used include:

• When you want to provide a simple interface to a complex system.
• When you want to hide the complexity of a system and only expose the necessary functionality.
• When you want to improve the readability and usability of a complex codebase.

The Facade pattern promotes loose coupling between the client and the complex system, allowing the client to interact with the system in a simplified way. It also makes the system more manageable, and it's easy to change the implementation of the complex system without affecting the client. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

The Facade design pattern is a structural pattern that provides a simplified interface to a complex system. The idea is to hide the system's complexity behind a single, easy-to-use interface. This makes it easier for clients to use the system, as they only need to interact with the facade and do not need to worry about the underlying complexity.

In C#, the Facade pattern can be implemented by creating a class called Facade, which acts as the simplified interface to the complex system. The Facade class contains methods that call the appropriate methods on the underlying classes of the system.

class Facade
{
    private SubsystemA subsystemA;
    private SubsystemB subsystemB;
    private SubsystemC subsystemC;

    public Facade()
    {
        subsystemA = new SubsystemA();
        subsystemB = new SubsystemB();
        subsystemC = new SubsystemC();
    }

    public void MethodA()
    {
        subsystemA.MethodA1();
        subsystemB.MethodB1();
    }

    public void MethodB()
    {
        subsystemB.MethodB2();
        subsystemC.MethodC1();
    }
}

The Facade class also simplifies the use of the system by clients by providing a simple interface that is easy to understand and use.

class Client
{
    public void ClientCode(Facade facade)
    {
        facade.MethodA();
        facade.MethodB();
    }
}

In this example, the Facade class provides a simplified interface for the Client class to interact with the complex system made up of SubsystemA, SubsystemB, and SubsystemC. As a result, the Client class does not need to know about the underlying complexity of the system and can use the Facade class to interact with the system and easily.

It is worth noting that the Facade pattern is not a substitute for good design, it is useful when you want to hide a complex system behind a simplified interface, but it can also make the code more rigid and harder to extend if not used correctly.

Learn more here, Facade Design Pattern In C# (c-sharpcorner.com).

14. What is the Adapter pattern, and when is it used?

The Adapter pattern is a design pattern that allows objects with incompatible interfaces to work together. It is used to translate the interface of one class into the interface expected by another class, allowing objects to work together that could not otherwise because of incompatible interfaces.

The Adapter pattern defines an adapter class that implements the interface expected by the client and holds a reference to the adaptee (the object that needs to be adapted). The adapter class forwards requests from the client to the adaptee and maps the response back to the client.

The Adapter pattern is often used when an existing class cannot be reused because its interface is incompatible with the client's interface. Some common examples of when the Adapter pattern is used include:

• When you want to use an existing class, its interface is incompatible with the client's interface.
• When you want to create a reusable class that cooperates with classes that have incompatible interfaces.
• When you want to use several existing subclasses and don't want to create a new subclass for each one.

The Adapter pattern promotes loose coupling between the client and the adaptee, allowing objects with incompatible interfaces to work together. It also allows you to reuse existing classes that would otherwise be incompatible, which makes the system more flexible and easier to extend. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

The Adapter design pattern is a structural pattern that allows two incompatible interfaces to work together. The idea is to create an adapter class that implements the target interface and wraps an instance of the adaptee class with the original interface. This allows the client to interact with the adaptee class through the adapter class as if it were the adaptee class itself.

In C#, the Adapter pattern can be implemented by creating an interface called ITarget, which defines the methods that the client expects, and an adapter class that implements this interface and wraps an instance of the adaptee class.

interface ITarget
{
    void MethodA();
}

class Adaptee
{
    public void MethodB()
    {
        // Implementation of MethodB
    }
}

class Adapter : ITarget
{
    private Adaptee _adaptee;

    public Adapter(Adaptee adaptee)
    {
        _adaptee = adaptee;
    }

    public void MethodA()
    {
        _adaptee.MethodB();
    }
}

The client can then interact with the adaptee class through the adapter class as if it were the adaptee class itself.

class Client
{
    public void ClientCode(ITarget target)
    {
        target.MethodA();
    }
}

class Program
{
    static void Main()
    {
        var adaptee = new Adaptee();
        var adapter = new Adapter(adaptee);
        var client = new Client();
        client.ClientCode(adapter);
    }
}

In this example, the Adaptee class has a method called MethodB, while the client expects a method called MethodA. The Adapter class implements the ITarget interface and wraps an instance of the Adaptee class. The client can then interact with the Adaptee class through the Adapter class as if it were the Adaptee class itself.

It's worth noting that the Adapter pattern can be implemented in multiple ways. In this example, I used a class adapter, but it can also be done using an object adapter, where the adapter class holds an instance of the adaptee class as a field and delegate the calls to the adaptee. Or even using C# built-in interfaces like IAdapter<TIn, TOut> that is defined by the .Net framework.

Learn more here, Adapter Design Pattern In C# (c-sharpcorner.com).

15. What is the Template Method pattern, and when is it used?

The Template Method pattern is a design pattern that defines the skeleton of an algorithm in a method, deferring some steps to subclasses. It is used to define the basic steps of an algorithm and allow subclasses to provide the implementation of one or more steps.

The Template Method pattern defines a template method in the superclass that provides the basic structure of the algorithm and calls one or more abstract methods, which are implemented by subclasses. In addition, subclasses can provide their implementation of abstract methods, allowing them to customize the algorithm.

The Template Method pattern is often used when you want to define the basic steps of an algorithm but allow subclasses to provide the implementation of one or more steps. Some common examples of when the Template Method pattern is used include:

• When you want to define the basic structure of an algorithm but allow subclasses to provide the implementation of one or more steps.
• When you want to provide a default implementation of an algorithm but allow subclasses to customize one or more steps.
• When you want to define an algorithm composed of several steps, some are optional and can be overridden by subclasses.

The Template Method pattern promotes code reuse, and it allows you to define the basic structure of an algorithm and allow subclasses to provide the implementation of one or more steps. It also makes the system more flexible and easier to extend. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

The Template Method pattern is a behavioral pattern that defines an algorithm's skeleton in a template method. It allows subclasses to provide the implementation for one or more steps of the algorithm. This allows subclasses to change the behavior of the algorithm without changing its structure.

In C#, the Template Method pattern can be implemented by creating an abstract class called AbstractClass, which defines the template method and the methods for the steps of the algorithm that can be overridden by subclasses.

abstract class AbstractClass
{
    public void TemplateMethod()
    {
        Step1();
        Step2();
        Step3();
    }

    protected virtual void Step1()
    {
        // Default implementation
    }

    protected virtual void Step2()
    {
        // Default implementation
    }

    protected virtual void Step3()
    {
        // Default implementation
    }
}

Concrete classes can then inherit from the abstract class and provide the implementation for one or more steps of the algorithm.

class ConcreteClass1 : AbstractClass
{
    protected override void Step2()
    {
        // Custom implementation for Step2
    }
}

class ConcreteClass2 : AbstractClass
{
    protected override void Step1()
    {
        // Custom implementation for Step1
    }

    protected override void Step3()
    {
        // Custom implementation for Step3
    }
}

The client code can then use the concrete classes, which will use the template method defined in the abstract class, but with the custom implementation for one or more steps provided by the concrete class.

class Client
{
    public void ClientCode()
    {
        var concrete1 = new ConcreteClass1();
        concrete1.TemplateMethod();

        var concrete2 = new ConcreteClass2();
        concrete2.TemplateMethod();
    }
}

In this example, the abstract class AbstractClass defines the template method TemplateMethod and the methods for the steps of the algorithm that subclasses can override. The concrete classes ConcreteClass1 and ConcreteClass2 inherit from the abstract class and provide the implementation for one or more steps of the algorithm. The client code uses the concrete classes, which use the template method defined in the abstract class but with the custom implementation for one or more steps provided by the concrete class.

Learn more here, Template Design Pattern in C# (c-sharpcorner.com).

16. What is the Iterator pattern, and when is it used?

The Iterator pattern is a design pattern that provides a way to traverse a collection of objects without exposing the underlying representation of the collection. It is used to access the elements of an aggregate object sequentially without exposing its underlying representation.

The Iterator pattern defines an Iterator interface that defines the methods for traversing the collection, such as next() and hasNext(). The concrete iterator class implements the Iterator interface and holds a reference to the underlying collection. The aggregate object, such as a list or a set, provides a factory method for creating the iterator.

The Iterator pattern is often used when you want to traverse a collection of objects without exposing the underlying representation of the collection. Some common examples of when the Iterator pattern is used include:

• When you want to traverse a collection of objects without exposing the underlying representation of the collection.
• When you want to provide multiple traversals of the same collection.
• When you want to abstract the traversal mechanism for different types of collections.

The Iterator pattern promotes loose coupling between the collection and the client, allowing you to traverse a collection of objects without exposing the underlying representation of the collection. It also allows you to provide multiple traversals of the same collection and abstracts the traversal mechanism for different types of collections. Additionally, it's a widely recognized and used pattern, and many frameworks and libraries have been built to implement it.

The Iterator design pattern is a behavioral design pattern that allows you to iterate over a collection of objects consistently without knowing the underlying data structure. This allows you to separate the responsibilities of the collection and the iterator, making it easier to add new types of collections and iterators.

In C#, the Iterator pattern can be implemented by creating an interface called IIterator, which defines the methods for iterating over a collection of objects.

interface IIterator<T>
{
    T First();
    T Next();
    bool IsDone();
    T CurrentItem();
}

A concrete implementation of the Iterator interface can then be created for a specific collection, which implements the methods for iterating over that collection.

class ConcreteIterator<T> : IIterator<T>
{
    private readonly List<T> _items;
    private int _current = 0;

    public ConcreteIterator(List<T> items)
    {
        _items = items;
    }

    public T First()
    {
        return _items[0];
    }

    public T Next()
    {
        var item = _items[_current];
        _current++;
        return item;
    }

    public bool IsDone()
    {
        return _current >= _items.Count;
    }

    public T CurrentItem()
    {
        return _items[_current];
    }
}

The collection class, such as ConcreteCollection, can then have a method to create the iterator.

class ConcreteCollection<T>
{
    private readonly List<T> _items = new List<T>();

    public IIterator<T> CreateIterator()
    {
        return new ConcreteIterator<T>(_items);
    }
}

The client code can then use the iterator to iterate over the collection without having to know the underlying data structure of the collection.

var collection = new ConcreteCollection<int>();
collection.Add(1);
collection.Add(2);
collection.Add(3);

var iterator = collection.CreateIterator();

while (!iterator.IsDone())
{
    var item = iterator.Next();
    Console.WriteLine(item);
}

The above example is just a basic example. The implementation details might vary based on the specific requirements and use cases; you can also use C# standard built-in interfaces like IEnumerable and IEnumerator to implement iterator patterns.

Learn more here, Iterator Design Pattern (c-sharpcorner.com).

17. What is the Mediator pattern, and when is it used?

The Mediator pattern is a design pattern that defines an object and encapsulates how a set of objects interact. It promotes loose coupling by keeping objects from explicitly referring to each other and allowing their interaction to be varied independently.

The Mediator pattern defines a mediator object that controls the communication between a set of objects called colleagues. The colleagues communicate with the mediator instead of communicating directly with each other. This allows the communication between colleagues to be varied independently and promotes loose coupling.

The Mediator pattern is often used when a set of objects communicate in well-defined but complex ways. Some common examples of when the Mediator pattern is used include:

• When the communication between a set of objects is complex and needs to be encapsulated.
• When you want to promote loose coupling between a set of objects.
• When you want to allow the communication between objects to be varied independently.

The Mediator pattern promotes loose coupling between a set of objects and allows the communication between objects to be varied independently. It also allows you to encapsulate the complex communication between a set of objects. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

The Mediator design pattern is a behavioral design pattern that allows objects to communicate with each other without having to know the identities of the other objects. This is done by introducing a mediator object that acts as a hub for communication between the other objects.

In C#, the Mediator pattern can be implemented by creating an interface called IMediator, which defines the methods for sending and receiving messages between objects.

interface IMediator
{
    void SendMessage(string message, object sender);
    void Register(object obj);
}

A concrete implementation of the Mediator interface can then be created, which handles the actual communication between objects.

class ConcreteMediator : IMediator
{
    private List<object> registeredObjects = new List<object>();

    public void Register(object obj)
    {
        registeredObjects.Add(obj);
    }

    public void SendMessage(string message, object sender)
    {
        // Send message to all registered objects, except the sender
        foreach (var obj in registeredObjects.Where(o => o != sender))
        {
            // Here, you can call a method on the object to handle the message
            // or use reflection to invoke a method on the object
        }
    }
}

Objects that want to communicate with each other can register with the mediator and send messages through it.

class ObjectA
{
    private IMediator mediator;
    public ObjectA(IMediator mediator)
    {
        this.mediator = mediator;
        this.mediator.Register(this);
    }

    public void SendMessage(string message)
    {
        this.mediator.SendMessage(message, this);
    }
}

Note that the above is a basic example and the details of implementation might vary based on the specific requirements and use cases.

Learn more here, Mediator Design Pattern Using C# (c-sharpcorner.com).

18. What is the Prototype pattern, and when is it used?

The Prototype pattern is a design pattern that creates new objects by copying existing objects rather than creating new objects from scratch. It is used to create new objects by copying existing objects rather than creating new objects from scratch, which can be more efficient and cost-effective.

The Prototype pattern defines a prototype interface that specifies a method for creating a copy of the object. Concrete classes implement the prototype interface and provide the implementation for the clone() method. The client code creates a new object by asking a prototype object to create a copy of itself.

The Prototype pattern is often used when creating a new object is expensive or complex, and it is more efficient to create a new object by copying an existing object. Some common examples of when the Prototype pattern is used include:

• When creating a new object is expensive or complex, it is more efficient to create a new object by copying an existing one.
• When the class of an object is not known at compile-time and needs to be determined at runtime.
• When the system needs to be independent of the way objects are created, composed, and represented.

The Prototype pattern promotes loose coupling between the client and the classes of the objects it creates, allowing the client to create new objects by copying existing objects rather than creating new objects from scratch. It also allows the system to be independent of how objects are created, composed, and represented. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

Here's an example of the Prototype design pattern implemented in C#:

abstract class Prototype
{
    public int Id { get; set; }
    public Prototype(int id)
    {
        this.Id = id;
    }
    public abstract Prototype Clone();
}

class ConcretePrototypeA : Prototype
{
    public ConcretePrototypeA(int id) : base(id) { }
    public override Prototype Clone()
    {
        return (Prototype)this.MemberwiseClone();
    }
}

class ConcretePrototypeB : Prototype
{
    public ConcretePrototypeB(int id) : base(id) { }
    public override Prototype Clone()
    {
        return (Prototype)this.MemberwiseClone();
    }
}

class Client
{
    static void Main()
    {
        Prototype prototypeA = new ConcretePrototypeA(1);
        Prototype cloneA = prototypeA.Clone();
        Console.WriteLine("Cloned: " + (cloneA.Id == prototypeA.Id)); // Output: "Cloned: True"

        Prototype prototypeB = new ConcretePrototypeB(2);
        Prototype cloneB = prototypeB.Clone();
        Console.WriteLine("Cloned: " + (cloneB.Id == prototypeB.Id)); // Output: "Cloned: True"
    }
}

Learn more here, Learn Design Pattern - Prototype Pattern (c-sharpcorner.com).

19. What is the Chain of Responsibility pattern, and when is it used?

The Chain of Responsibility pattern is a design pattern that allows a series of objects to process a request, with each object having the opportunity to handle a request or pass it on to the next object in the chain. It is used to process a request through a series of objects, with each object having the opportunity to handle the request or pass it on to the next object in the chain.

The Chain of Responsibility pattern defines a chain of objects, where each object has a reference to the next object in the chain. The first object in the chain receives the request and then passes it on to the next object in the chain if it cannot handle it. The request is processed until it is handled by an object in the chain or reaches the end of the chain.

The Chain of Responsibility pattern is often used when a request needs to be handled by multiple objects, and the specific object that handles the request is not known in advance. Some common examples of when the Chain of Responsibility pattern is used include:

• When a request needs to be handled by multiple objects, the specific object that handles the request is not known in advance.
• When a set of objects that can handle a request should be specified dynamically.
• When a request should be handled by the first object in a chain of objects that can handle it.

The Chain of Responsibility pattern promotes loose coupling between the objects in the chain and the client, and it allows the set of objects that can handle a request to be specified dynamically. It also allows a request to be handled by the first object in a chain of objects that can handle it. Additionally, it's a pattern that is widely recognized and used, and many frameworks and libraries have been built to implement it.

In C#, the Chain of Responsibility pattern can be implemented using a LinkedList or an array of objects that implement a common interface for handling requests. The interface typically includes a method for handling the request and a property for setting the next object in the chain. The class that sends the request iterates through the chain of objects, calling the handling method on each one until the request is handled or the end of the chain is reached.

Here is an example in C#:

interface IHandler
{
    IHandler Next { get; set; }
    void HandleRequest(string request);
}

class ConcreteHandlerA : IHandler
{
    public IHandler Next { get; set; }
    public void HandleRequest(string request)
    {
        if (request == "A")
        {
            Console.WriteLine("ConcreteHandlerA handled the request.");
        }
        else if (Next != null)
        {
            Next.HandleRequest(request);
        }
    }
}

class ConcreteHandlerB : IHandler
{
    public IHandler Next { get; set; }
    public void HandleRequest(string request)
    {
        if (request == "B")
        {
            Console.WriteLine("ConcreteHandlerB handled the request.");
        }
        else if (Next !=

In this example, the IHandler interface defines the contract for handling requests, with a property for setting the next object in the chain and a method for handling the request. The ConcreteHandlerA and ConcreteHandlerB classes implement the IHandler interface and define their own logic for handling specific types of requests. For example, the Client class sets up the chain of objects and sends a request to the first object in the chain. If the request is not handled by the first object, it is passed to the next object in the chain, and so on, until the request is handled or the end of the chain is reached.

Learn more here, Chain Of Responsibility Design Pattern (c-sharpcorner.com).

Summary

In this article, you learned the basics of software design patterns and why we need design patterns. We also learned various types of design patterns and when to use them. In the end, we also saw how these design patterns could be implemented in our software applications.