Design Principles: Dependency Inversion Principle

The Dependency Inversion Principle (DIP) is one of the most powerful principles of object-oriented programming. It serves as the backbone for creating systems that are decoupled, testable, and easy to maintain.

The Dependency Inversion Principle states:

“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.”

In simpler terms:

High-level logic (like business rules) should not rely on implementation details (like database access or API calls).

Both high-level and low-level code should depend on abstractions (like interfaces or abstract classes), allowing for flexibility and extensibility.

Let’s take the example of a notification system. The goal is to send notifications via email and SMS.

Initial Design (Violates DIP)


class EmailService:
    def send_email(self, message):
        print(f"Sending Email: {message}")

class SMSService:
    def send_sms(self, message):
        print(f"Sending SMS: {message}")

class Notification:
    def __init__(self):
        self.email_service = EmailService()
        self.sms_service = SMSService()

    def send(self, message):
        self.email_service.send_email(message)
        self.sms_service.send_sms(message)

Issue with the above

Tight Coupling: The Notification class depends directly on EmailService and SMSService.

Lack of Extensibility: Adding new notification types (e.g., push notifications) requires modifying the Notification class.

Testing Challenges: It’s difficult to replace EmailService and SMSService with mock implementations during testing.

To adhere to DIP, we introduce an abstraction (NotificationService) that both EmailService and SMSService implement. The Notification class will depend on this abstraction, not the concrete implementations.

Improved Design


from abc import ABC, abstractmethod

# Abstract Class
class NotificationService(ABC):
    @abstractmethod
    def send(self, message):
        pass

# Concrete Implementations
class EmailService(NotificationService):
    def send(self, message):
        print(f"Sending Email: {message}")

class SMSService(NotificationService):
    def send(self, message):
        print(f"Sending SMS: {message}")

# High-Level Module
class Notification:
    def __init__(self, services: list[NotificationService]):
        self.services = services

    def send(self, message):
        for service in self.services:
            service.send(message)

# Example Usage
email_service = EmailService()
sms_service = SMSService()

notifier = Notification(services=[email_service, sms_service])
notifier.send("Hello, this is a test notification!")

Benefits of the Refactored Design

Decoupling - The Notification class now relies solely on the NotificationService abstraction. We can modify, replace, or remove email and SMS services without touching the Notification class.

Extensibility - New notification services (like push notifications) can be added by simply implementing the NotificationService interface

Testability - We can easily test the system by using mock services that implement NotificationService.


classDiagram
    class NotificationService {
        <<interface>>
        +send(message): void
    }

    class EmailService {
        +send(message): void
    }

    class SMSService {
        +send(message): void
    }

    class Notification {
        -services: list~NotificationService~
        +send(message): void
    }

    NotificationService <|-- EmailService
    NotificationService <|-- SMSService
    Notification --> NotificationService

Conclusion

The Dependency Inversion Principle fosters decoupled and maintainable code by inverting the traditional dependency structure. By depending on abstractions instead of concrete implementations, software systems become flexible, testable, and resilient to changes.

When combined with other SOLID principles, DIP leads to robust and scalable applications that are easy to extend and adapt to future requirements.