🧠 Mastering 5 Design Patterns in C# - Part 5

✨ Introduction

Continuing our comprehensive series on design patterns in C#, this fourth part introduces 5 additional patterns that enhance modularity, control flow, and system extensibility. Still using the notification system context, we’ll explore:

• Dependency Injection

• Null Object

• Facade

• Bridge

• Data Mapper

---

🧩 1. Dependency Injection – Inversion of Control

✅ Intent

Decouple object creation from its usage by injecting dependencies.

🎯 Purpose

Use when you want to promote loose coupling and testability, especially in systems with multiple interchangeable services.

🧩 Code

public interface INotificationService
{
    void Send(string message);
}

public class EmailService : INotificationService
{
    public void Send(string message) => Console.WriteLine($"Email: {message}");
}

public class NotificationSender
{
    private readonly INotificationService _service;

    public NotificationSender(INotificationService service)
    {
        _service = service;
    }

    public void Send(string message)
    {
        _service.Send(message);
    }
}

🧠 Explanation

• NotificationSender receives its dependency via constructor injection.

👍 Pros

• Highly testable.

• Promotes loose coupling.

👎 Cons

• Requires setup (e.g., DI container).

• Can be verbose in small apps.

---

🚫 2. Null Object – Safe Default Behavior

✅ Intent

Provide a default object that does nothing instead of using null.

🎯 Purpose

Use when you want to avoid null checks and ensure safe behavior when no service is available.

🧩 Code

public class NullNotificationService : INotificationService
{
    public void Send(string message)
    {
        Console.WriteLine("No notification sent.");
    }
}

🧠 Explanation

• Implements the same interface but performs no action.

👍 Pros

• Eliminates null checks.

• Simplifies control flow.

👎 Cons

• May hide errors.

• Can lead to silent failures.

---

🎯 3. Facade – Simplified Interface

✅ Intent

Provide a unified interface to a set of interfaces in a subsystem.

🎯 Purpose

Use when you want to simplify complex subsystems and expose a clean API to clients.

🧩 Code

public class NotificationFacade
{
    private readonly EmailService _email = new();
    private readonly SmsService _sms = new();

    public void SendAll(string message)
    {
        _email.Send(message);
        _sms.Send(message);
    }
}

🧠 Explanation

• NotificationFacade wraps multiple services into one method.

👍 Pros

• Simplifies usage.

• Hides complexity.

👎 Cons

• Can become bloated.

• May reduce flexibility.

---

🌉 4. Bridge – Decoupling Abstraction from Implementation

✅ Intent

Separate abstraction from implementation so they can vary independently.

🎯 Purpose

Use when you want to combine multiple dimensions of variation, like notification types and delivery methods.

🧩 Code

public interface INotificationSender
{
    void Send(string message);
}

public abstract class Notification
{
    protected INotificationSender _sender;

    protected Notification(INotificationSender sender)
    {
        _sender = sender;
    }

    public abstract void Notify(string message);
}

public class UrgentNotification : Notification
{
    public UrgentNotification(INotificationSender sender) : base(sender) { }

    public override void Notify(string message)
    {
        Console.WriteLine("Urgent:");
        _sender.Send(message);
    }
}

🧠 Explanation

• Notification is the abstraction; INotificationSender is the implementation.

👍 Pros

• Flexible combinations.

• Reduces class explosion.

👎 Cons

• Adds abstraction layers.

• Can be harder to trace.

---

🗃️ 5. Data Mapper – Separation of Data Access

✅ Intent

Map between in-memory objects and database records.

🎯 Purpose

Use when you want to separate business logic from persistence logic, especially in layered architectures.

🧩 Code

public class Notification
{
    public int Id { get; set; }
    public string Message { get; set; }
}

public class NotificationMapper
{
    public Notification MapFromDbRow(Dictionary<string, object> row)
    {
        return new Notification
        {
            Id = (int)row["Id"],
            Message = (string)row["Message"]
        };
    }
}

🧠 Explanation

• NotificationMapper converts raw data into domain objects.

👍 Pros

• Clean separation of concerns.

• Easier to test business logic.

👎 Cons

• Requires manual mapping.

• Can be repetitive without tools.

---

🧾 Conclusion

These five patterns further strengthen your architectural toolbox:

• Dependency Injection promotes loose coupling.

• Null Object ensures safe defaults.

• Facade simplifies complex systems.

• Bridge enables flexible abstractions.

• Data Mapper separates data access from logic.

With 25 patterns now covered, you’re well-equipped to design clean, scalable, and maintainable C# applications.

#CSharp #DesignPatterns #DotNet #SoftwareArchitecture #DependencyInjection #CleanCode #BackendDev #ScalableSystems #Developer #Development #DependecyInjection #NullObjectPattern #FacadePattern #BridgePattern #DataMapperPattern