DEV Community: Omar Faruque Shamim

Dependency Inversion Principle (DIP)

Omar Faruque Shamim — Tue, 31 Dec 2024 15:13:18 +0000

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

The Dependency Inversion Principle aims to reduce coupling between different parts of a system by ensuring that high-level components do not depend on low-level implementation details. Instead, both should rely on abstractions (e.g., interfaces or abstract classes).

Why Use the Dependency Inversion Principle?

Improves Flexibility and Reusability: By relying on abstractions, components can be easily replaced, reused, or tested without altering dependent code.

Simplifies Testing:
You can easily mock or stub abstractions for unit testing without involving actual implementations.
Facilitates Dependency Injection: Encourages the use of dependency injection frameworks, promoting clean and maintainable code.
*Supports Open/Closed Principle: * High-level modules remain closed for modification but open for extension through abstraction.
Promotes Modular Design: Decouples systems into loosely connected modules, making the system more robust and adaptable to changes.

How to Implement the Dependency Inversion Principle?

Abstract Behavior: Define interfaces or abstract classes that specify the required functionality instead of hard-coding dependencies.
Inject Dependencies: Use dependency injection to provide implementations of abstractions to high-level modules.
Avoid Concrete Instantiations: High-level modules should not directly instantiate low-level modules. Instead, they should rely on abstractions.
DIP Implementation Example

Without DIP (Violating the Principle):

Consider a payment processing system where a PaymentService depends directly on a CreditCardProcessor implementation.

public class CreditCardProcessor
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of ${amount}");
    }
}

public class PaymentService
{
    private readonly CreditCardProcessor _creditCardProcessor;

    public PaymentService()
    {
        _creditCardProcessor = new CreditCardProcessor(); // Tight coupling
    }

    public void MakePayment(decimal amount)
    {
        _creditCardProcessor.ProcessPayment(amount);
    }
}

Problems:
Tight Coupling: PaymentService is tightly coupled to CreditCardProcessor, making it hard to replace or extend.

Low Testability: Testing PaymentService would require an actual CreditCardProcessor.

Difficult to Extend: Adding a new payment processor (e.g., PayPal) requires modifying PaymentService.

With DIP (Following the Principle):

Refactor to introduce an abstraction for payment processing.

// Define an abstraction
public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

// Concrete implementation 1: Credit card processor
public class CreditCardProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of ${amount}");
    }
}

// Concrete implementation 2: PayPal processor
public class PayPalProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing PayPal payment of ${amount}");
    }
}

// High-level module depends on abstraction
public class PaymentService
{
    private readonly IPaymentProcessor _paymentProcessor;

    // Dependency injection
    public PaymentService(IPaymentProcessor paymentProcessor)
    {
        _paymentProcessor = paymentProcessor;
    }

    public void MakePayment(decimal amount)
    {
        _paymentProcessor.ProcessPayment(amount);
    }
}

Benefits:

Decoupled Design: PaymentService depends on IPaymentProcessor instead of specific implementations.

Flexible and Extendable: Adding a new payment processor only requires implementing the IPaymentProcessor interface without modifying PaymentService.

Easy to Test: Mock or stub IPaymentProcessor during testing without involving actual processors.

Conclusion

The Dependency Inversion Principle encourages designing applications in a way that high-level modules are insulated from changes in low-level modules. By depending on abstractions, the system becomes more modular, testable, and adaptable to future requirements. This principle is central to creating scalable and maintainable applications, especially when combined with Dependency Injection frameworks.

Interface Segregation Principle (ISP)

Omar Faruque Shamim — Tue, 31 Dec 2024 15:03:15 +0000

Clients should not be forced to depend on interfaces or methods they do not use.

This means, interfaces should be small and specific, containing only methods that are relevant to the client. This avoids the problem of having a single large interface with methods that may not be applicable to all its clients.

Why Use the Interface Segregation Principle?

Avoids Code Bloat: Large interfaces force clients to implement methods they don’t need, leading to unnecessary complexity and maintenance challenges.
Enhances Flexibility: Smaller, focused interfaces are easier to use, modify, and extend without impacting unrelated parts of the code.
Improves Code Readability and Maintenance: Segregated interfaces are easier to understand because they focus on specific behaviors.
Reduces Coupling: Ensures that classes are dependent only on the functionality they need, making the system more modular and robust to change.
Prevents Unused Implementations: Classes implementing a large interface with irrelevant methods often include placeholder or empty implementations, which can confuse developers and lead to potential bugs.

How to Implement the Interface Segregation Principle?

Identify Responsibilities: Break down large, multi-purpose interfaces into smaller, specific ones based on distinct behaviors.
Design Focused Interfaces: Each interface should define methods related to a single responsibility or closely related functionality.
Use Composition Over Inheritance: Compose classes using multiple smaller interfaces rather than inheriting from a large interface.

How to Implement ISP

Without ISP (Violating the Principle):
Here’s an example of a booking system where an INotification interface is used to handle different types of notifications.

public interface INotification
{
    void SendEmail(string message);
    void SendSMS(string message);
    void SendPushNotification(string message);
}

public class EmailNotification : INotification
{
    public void SendEmail(string message)
    {
        Console.WriteLine("Email sent: " + message);
    }

    public void SendSMS(string message)
    {
        throw new NotImplementedException(); // Not needed
    }

    public void SendPushNotification(string message)
    {
        throw new NotImplementedException(); // Not needed
    }
}

Problems:
EmailNotification has to implement methods it doesn’t use (SendSMS and SendPushNotification).
Adding new notification types or methods will affect all classes implementing INotification, even if they don’t use them.

With ISP (Following the Principle):
Refactor the INotification interface into smaller, specific interfaces.

Liskov Substitution Principle (LSP)

Omar Faruque Shamim — Tue, 31 Dec 2024 15:02:51 +0000

Subtypes must be substitutable for their base types without altering the correctness of the program.

This means, if you have a class B that extends a class A, you should be able to replace A with B without breaking the functionality of your application. Apply LSP in inheritance scenarios and when using polymorphism.

Why is LSP Important?

Ensures Reliable Substitution: Promotes a design where derived classes work seamlessly in place of their base class.
Improves Maintainability: Ensures that new derived classes won’t break the existing code.
Enhances Reusability: Enables the use of polymorphism effectively, as derived classes adhere to the behavior of their base class.
Prevents Violations of Expected Behavior: Protects against surprising behaviors caused by derived classes altering functionality unexpectedly.
Extensibility: Adding a new payment method (e.g., DigitalWalletProcessor) requires implementing the same base class, ensuring consistency.

How to Implement SRP

Scenario: Payment System
You’re developing a system to process payments. Initially, there’s a base class PaymentProcessorand a derived class CreditCardProcessor. Later, a new requirement arises to handle cash payments.

Without LSP (Violation):

public class PaymentProcessor
{
    public virtual void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing payment of {amount:C}.");
    }
}

public class CreditCardProcessor : PaymentProcessor
{
    public override void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of {amount:C}.");
    }
}

public class CashPaymentProcessor : PaymentProcessor
{
    public override void ProcessPayment(decimal amount)
    {
        if (amount > 1000)
        {
            throw new InvalidOperationException("Cash payments cannot exceed $1000.");
        }
        Console.WriteLine($"Processing cash payment of {amount:C}.");
    }
}

Here’s the issue:

The base class PaymentProcessorassumes any amount can be processed, but the CashPaymentProcessoradds a restriction (amount <= 1000), violating the principle.
If you use the CashPaymentProcessorwhere a PaymentProcessoris expected, the client might encounter unexpected exceptions.

With LSP (Solution):
Refactor the code to separate concerns and ensure substitutability. Use interfaces or base classes that clearly define the responsibilities of each payment type.

public abstract class PaymentProcessor
{
    public abstract void ProcessPayment(decimal amount);
}

public class CreditCardProcessor : PaymentProcessor
{
    public override void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of {amount:C}.");
    }
}

public class CashPaymentProcessor : PaymentProcessor
{
    public override void ProcessPayment(decimal amount)
    {
        if (amount > 1000)
        {
            Console.WriteLine("Payment failed: Cash payments cannot exceed $1000.");
            return;
        }
        Console.WriteLine($"Processing cash payment of {amount:C}.");
    }
}

Here’s how it works with LSP:

public void ProcessTransaction(PaymentProcessor paymentProcessor, decimal amount)
{
    paymentProcessor.ProcessPayment(amount);
}

You can pass either CreditCardProcessor or CashPaymentProcessorto ProcessTransaction, and the behavior will always align with the expectations of the base class.
The CashPaymentProcessor does not throw unexpected exceptions; it gracefully handles cases exceeding its limit.

Open/Closed Principle (OCP)

Omar Faruque Shamim — Sun, 08 Dec 2024 03:47:04 +0000

Software entities (classes, modules, functions) should be open for extension but closed for modification.

This means:
Open for Extension: You should be able to add new functionality to an existing module or class without altering its existing code.

Closed for Modification: Once a class is written and tested, you should not need to modify it to add new functionality.

Why is OCP Important?

Preserves Stability: Existing code remains untouched, reducing the risk of introducing new bugs.
Enhances Flexibility: Makes the system adaptable to new requirements without rewriting or breaking existing logic.
Supports Scalability: New behaviors can be added with minimal effort.
Aligns with Agile Practices: Easily adapts to changing requirements, a common scenario in software development.

How Violates OCP?

OCP is violated when:

Adding new behavior requires modifying existing classes or methods.
This leads to tight coupling, making it harder to maintain or extend the system.

Example of OCP Violation:
Imagine a PaymentProcessorclass that handles different payment methods:

public class PaymentProcessor
{
    public void ProcessPayment(string paymentType, decimal amount)
    {
        if (paymentType == "CreditCard")
        {
            Console.WriteLine($"Processing credit card payment of {amount:C}.");
        }
        else if (paymentType == "Cash")
        {
            Console.WriteLine($"Processing cash payment of {amount:C}.");
        }
    }
}

Problems:

Adding a new payment type requires modifying the ProcessPayment method.
Every change increases the likelihood of bugs in existing functionality.
This violates OCP because the class is not closed for modification.

How to Implement Class-Level OCP

OCP can be implemented using techniques like polymorphism, composition, and strategy patterns. Below are steps for implementation using class-level OCP with execution flow.

Step 1: Define an Abstraction
Create an abstract class or interface to define common behavior.

public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

Step 2: Create Concrete Implementations
Implement the interface for each payment type.

public class CreditCardProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of {amount:C}.");
    }
}

public class CashPaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        if (amount > 1000)
        {
            Console.WriteLine("Cash payment cannot exceed $1000.");
            return;
        }
        Console.WriteLine($"Processing cash payment of {amount:C}.");
    }
}

Step 3: Use Abstraction in the Client
The client depends on the abstraction (IPaymentProcessor) and can dynamically work with any implementation.

public class PaymentHandler
{
    private readonly IPaymentProcessor _paymentProcessor;

    public PaymentHandler(IPaymentProcessor paymentProcessor)
    {
        _paymentProcessor = paymentProcessor;
    }

    public void HandlePayment(decimal amount)
    {
        _paymentProcessor.ProcessPayment(amount);
    }
}

Step 4: Call PaymentHandler
Create and use the appropriate payment processor at runtime.

var creditCardProcessor = new CreditCardProcessor();
var paymentHandler = new PaymentHandler(creditCardProcessor);
paymentHandler.HandlePayment(500);

var cashProcessor = new CashPaymentProcessor();
var cashPaymentHandler = new PaymentHandler(cashProcessor);
cashPaymentHandler.HandlePayment(1200);

Execution Flow

The PaymentHandlerrelies on the IPaymentProcessorinterface.
Adding a new payment type (e.g., DigitalWalletProcessor) requires creating a new class that implements IPaymentProcessor.
No changes are made to the existing PaymentHandleror other classes.

How to Implement Method-Level OCP

For finer-grained control (specific method behavior), we can use strategies or composition to inject new logic into a method.

Example: Discount Calculation

public interface IDiscountStrategy
{
    decimal CalculateDiscount(decimal price);
}

public class RegularDiscount : IDiscountStrategy
{
    public decimal CalculateDiscount(decimal price) => price * 0.1m; // 10% discount
}

public class VIPDiscount : IDiscountStrategy
{
    public decimal CalculateDiscount(decimal price) => price * 0.2m; // 20% discount
}

public class DiscountCalculator
{
    public decimal Calculate(decimal price, IDiscountStrategy discountStrategy)
    {
        return discountStrategy.CalculateDiscount(price);
    }
}

Usage:

var calculator = new DiscountCalculator();
decimal discountedPrice = calculator.Calculate(1000, new VIPDiscount());
Console.WriteLine($"Discounted Price: {discountedPrice:C}");

Flow:
New discount types can be added without modifying the DiscountCalculator.

By following OCP, you build systems that are easier to extend and maintain while reducing risks of breaking existing functionality.

Single Responsibility Principle (SRP)

Omar Faruque Shamim — Thu, 05 Dec 2024 04:09:18 +0000

Each class should have only one responsibility or reason to change.

This means each class should focus on a single functionality or responsibility and not combine unrelated tasks.

Why is SRP Important?

Simplifies Maintenance : Changes to a specific responsibility are isolated, reducing the risk of impacting unrelated code.
Improves Code Readability : Classes are smaller and easier to understand.
Enhances Reusability : Class can be reused in different contexts without carrying unnecessary responsibilities.
Eases Testing : Testing a single responsibility is straightforward, as the class has fewer dependencies.
Reduces Coupling : Avoids tightly coupling unrelated functionalities, making the codebase more flexible.

How to Apply SRP

Here’s an example of implementing SRP for a ticket booking scenario. The solution demonstrates how to handle booking logic, database persistence, email notifications, and error logging using separate classes.

Classes Overview
BookingService: Core business logic for booking tickets.
DatabaseService: Handles database interactions.
EmailService: Sends email notifications.
LoggerService: Logs errors or other information.

Code Implementation

LoggerService Handles logging operations.

public class LoggerService
{
    public void LogError(string message)
    {
        // Log error to a file or monitoring system
        Console.WriteLine($"Error: {message}");
    }

    public void LogInfo(string message)
    {
        // Log general information
        Console.WriteLine($"Info: {message}");
    }
}

EmailService Handles sending emails.

public class EmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        // Simulated email sending logic
        Console.WriteLine($"Email sent to {to} with subject: {subject}");
    }
}

DatabaseService Handles database operations.

public class DatabaseService
{
    public void SaveBooking(string bookingDetails)
    {
        // Simulated database save logic
        Console.WriteLine($"Booking saved: {bookingDetails}");
    }
}

BookingService Core business logic for ticket booking. It orchestrates the other services.

public class BookingService
{
    private readonly DatabaseService _databaseService;
    private readonly EmailService _emailService;
    private readonly LoggerService _loggerService;

    public BookingService(DatabaseService databaseService, EmailService emailService, LoggerService loggerService)
    {
        _databaseService = databaseService;
        _emailService = emailService;
        _loggerService = loggerService;
    }

    public void BookTicket(string userEmail, string bookingDetails)
    {
        try
        {
            // Step 1: Business logic for booking (e.g., validation, seat availability)
            _loggerService.LogInfo("Booking process started.");

            // Step 2: Save booking to the database
            _databaseService.SaveBooking(bookingDetails);

            // Step 3: Send confirmation email
            _emailService.SendEmail(userEmail, "Booking Confirmation", "Your booking is confirmed!");

            _loggerService.LogInfo("Booking process completed successfully.");
        }
        catch (Exception ex)
        {
            // Step 4: Log any errors
            _loggerService.LogError($"Error during booking: {ex.Message}");
        }
    }
}

Program Execution Tie everything together and simulate the booking process.

public class Program
{
    public static void Main(string[] args)
    {
        // Dependency setup
        var databaseService = new DatabaseService();
        var emailService = new EmailService();
        var loggerService = new LoggerService();

        var bookingService = new BookingService(databaseService, emailService, loggerService);

        // Simulated booking details
        string userEmail = "user@example.com";
        string bookingDetails = "Flight: XYZ123, Date: 2024-12-01, Seat: 12A";

        // Book the ticket
        bookingService.BookTicket(userEmail, bookingDetails);
    }
}

Execution Flow

Business Logic Execution: Booking process begins with validation and checks.
Database Save: The booking details are stored using DatabaseService.
Email Notification: A confirmation email is sent using - EmailService.
Error Handling: Any exceptions during the process are logged by LoggerService.

This approach ensures a clean, modular design while adhering to SOLID principles.

SOLID Design Principles

Omar Faruque Shamim — Wed, 04 Dec 2024 12:03:45 +0000

SOLID refers to five core design principles that promote software maintainability, scalability, and robustness. These principles guide developers to create software that is easier to understand, modify, and extend.

1. Single Responsibility Principle (SRP)
Each class should have only one responsibility or reason to change.

2. Open/Closed Principle (OCP)
Software entities (classes, modules, functions) should be open for extension but closed for modification.

3. Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types without altering the correctness of the program.

4. Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces or methods they do not use.

5. Dependency Inversion Principle (DIP)
High-level modules (e.g., business logic) should not depend on low-level modules (e.g., data access or utility classes). Both should depend on abstractions (e.g., interfaces or abstract classes). Abstractions should not depend on details. Details should depend on abstractions.

Benefits of SOLID Design Principles

Improved Maintainability

Code is easier to read and understand.
Modifications can be made without breaking existing functionality.

Enhanced Scalability

New features can be added without extensive changes to the existing codebase.

Better Testability

Code designed with SOLID principles is modular, making unit testing straightforward.

Reduced Coupling

Loose coupling between components makes the system more flexible and adaptable.

Improved Reusability

Well-defined responsibilities and modular components enable reuse across different projects.

Facilitates Team Collaboration

Clearly defined responsibilities make it easier for team members to work on different parts of the codebase.

By following SOLID principles, developers can create software that is more adaptable to changing requirements, while reducing technical debt.

Single Responsibility Principle

Omar Faruque Shamim — Wed, 13 Nov 2024 11:51:31 +0000

A class or module should have only one reason to change. This means that a class should have only one responsibility or job to do, and all its methods should be related to that job. This makes the code easier to understand, modify, and test.

Benefits:

Code will be easier to understand
Better maintainability
Testability
Parallel Development
Reusability

How to implement SRP
Project Requirement:

The application should be able to Add and Delete employee
With every add and delete one email should be sent
In case of exception, a text log file will be generated

Solution 1: Without SRP Principles
We can send an email and create a log of both Add & Delete methods separately. But if any issues arise we have to solve both methods which is not a good practice.

public class Employee
    {
        public void Add()
        {
            try
            {
                Console.WriteLine("Add Employee");
                // Then write code for sending email
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.ToString());
            }
        }

        public void Delete()
        {
            try
            {
                Console.WriteLine("Delete Employee");
                // Then write code for sending email
            }
            catch (Exception ex) 
            {
                Console.WriteLine(ex.ToString()); 
            }
        }
    }

Solution 2: Using SRP Principles

So we create Ilogger and IMailer interfaces and implement these interfaces with two classes.
Mailer class takes responsibility for sending email
The logger class takes responsibility for creating the log

Instance create from employee constructor and then calling email-sender & logger method using those instance

public interface IMailer
 {
    void SendEmail();
 }

 public class Mailer : IMailer
    {
        public void SendEmail()
        {
            //write code for sending email.
        }
    }

 public interface ILogger
    {
        void LogException();
    }
    public class Logger : ILogger
    {
        public void LogException()
        {
            //write code for saving log exceptions.
        }
    }

interface IEmployee
    {
        void Add();
        void Delete();
    }
    public class Employee: IEmployee
    {
        ILogger _logger;
        IMailer _mailer;
        public Employee()
        {
            _logger = new Logger();
            _mailer = new Mailer();
        }   
        public void Add()
        {
            try
            {
                Console.WriteLine("Add Employee");
                _mailer.SendEmail();
            }
            catch (Exception ex)
            {
                _logger.LogException();
            }
        }
        public void Delete()
        {
            try
            {
                Console.WriteLine("Add Employee");
                _mailer.SendEmail();
            }
            catch (Exception ex)
            {
                _logger.LogException();
            }
        }
    }