Behavioral Design Patterns

Behavioral Design Patterns (C# / .NET)


Definition

  • Focus on communication between objects
  • Defines how objects interact and share responsibilities

Purpose

  • Improve communication flow
  • Reduce tight coupling between objects
  • Make behavior dynamic and flexible
  • Encapsulate business logic

Types with Real-Time Usage

1. Strategy Pattern

Idea: Change behavior at runtime

Real Scenario: Tax / Discount calculation in invoice

public interface ITaxStrategy
{
    decimal Calculate(decimal amount);
}

public class GstTax : ITaxStrategy
{
    public decimal Calculate(decimal amount) => amount * 0.18m;
}

public class NoTax : ITaxStrategy
{
    public decimal Calculate(decimal amount) => 0;
}

public class InvoiceService
{
    private readonly ITaxStrategy _tax;

    public InvoiceService(ITaxStrategy tax)
    {
        _tax = tax;
    }

    public decimal GetTotal(decimal amount)
    {
        return amount + _tax.Calculate(amount);
    }
}
  

2. Observer Pattern

Idea: One object notifies multiple objects

Real Scenario: Order placed → Email, SMS, Notification triggered

public interface IObserver
{
    void Update(string message);
}

public class EmailService : IObserver
{
    public void Update(string message)
    {
        Console.WriteLine($"Email: {message}");
    }
}

public class Order
{
    private List<IObserver> _observers = new();

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

    public void Notify(string message)
    {
        foreach (var obs in _observers)
            obs.Update(message);
    }
}
  

3. Command Pattern

Idea: Encapsulate request as an object

Real Scenario: Button click → Execute action (Save, Delete)

public interface ICommand
{
    void Execute();
}

public class CreateInvoiceCommand : ICommand
{
    public void Execute()
    {
        Console.WriteLine("Invoice Created");
    }
}

ICommand command = new CreateInvoiceCommand();
command.Execute();
  

4. Mediator Pattern

Idea: Central object controls communication

Real Scenario: Chat system / multiple services interaction

public class Mediator
{
    public void Send(string message, User user)
    {
        Console.WriteLine($"{user.Name}: {message}");
    }
}

public class User
{
    private readonly Mediator _mediator;
    public string Name { get; }

    public User(Mediator mediator, string name)
    {
        _mediator = mediator;
        Name = name;
    }

    public void Send(string message)
    {
        _mediator.Send(message, this);
    }
}
  

Pros

  • Loose coupling between objects
  • Flexible and scalable behavior
  • Easier to extend features
  • Better separation of concerns

Cons

  • More classes and complexity
  • Harder debugging
  • Learning curve

When to Use

  • When multiple objects need to communicate
  • When behavior needs to change dynamically
  • When reducing direct dependency is important
  • When implementing event-driven systems

Quick Summary Table

Type Focus Main Goal
Creational Object Creation Flexible object creation
Structural Object Structure Simplify relationships
Behavioral Object Interaction Better communication

Mapping to Your .NET Project

Feature Pattern
Tax / Discount logic Strategy
Order notifications Observer
API actions (Create/Update) Command
Service coordination Mediator

Comments

Popular posts from this blog

Promises in Angular

Debouncing & Throttling in RxJS: Optimizing API Calls and User Interactions

Comprehensive Guide to C# and .NET Core OOP Concepts and Language Features