SOLID Principles - Dependency Inversion Principle (DIP)

19/8/2023
3-minute read

Dependency Inversion Principle (DIP) in Ruby: A Practical Exploration

The Dependency Inversion Principle (DIP) is one of the SOLID principles that promotes flexibility and maintainability in software design. It does so by encouraging decoupling between high-level modules (which contain core application logic) and low-level modules (which provide specific implementations). In this article, we’ll explore DIP through multiple Ruby examples.

Understanding the Dependency Inversion Principle

DIP states that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. This ensures that changes in low-level modules do not directly impact high-level modules, making the system more adaptable and scalable.

Example 1: Violating DIP

Consider a scenario where a high-level module (OrderProcessor) directly depends on a low-level module (PaymentGateway):

class OrderProcessor
  def initialize(payment_gateway)
    @payment_gateway = payment_gateway
  end

  def process_order(order)
    # Code to process the order using a specific payment gateway
    @payment_gateway.process_payment(order.total)
  end
end

class PaymentGateway
  def process_payment(amount)
    # Code to process payment
  end
end

Here, OrderProcessor is tightly coupled to PaymentGateway, violating DIP. If we need to switch to a different payment gateway, we must modify OrderProcessor, which is undesirable.

Refactoring for DIP Compliance

To adhere to DIP, we introduce an abstraction (an interface or an abstract class) that both high-level and low-level modules depend on:

class OrderProcessor
  def initialize(payment_processor)
    @payment_processor = payment_processor
  end

  def process_order(order)
    # Code to process the order using the injected payment processor
    @payment_processor.process_payment(order.total)
  end
end

class PaymentProcessor
  def process_payment(amount)
    raise NotImplementedError, "Subclasses must implement this method"
  end
end

class StripePaymentProcessor < PaymentProcessor
  def process_payment(amount)
    # Code to process payment via Stripe
  end
end

Now, OrderProcessor depends on the abstraction (PaymentProcessor) instead of a concrete implementation. This allows us to inject different payment processors without modifying OrderProcessor.

Example 2: Applying DIP to Notification Sending

Consider a notification system where a class sends notifications:

class NotificationSender
  def send_notification(message)
    # Code to send a notification
  end
end

This design tightly couples the implementation to the notification logic. A DIP-compliant approach introduces an abstraction:

class OrderProcessor
  def initialize(notification_service)
    @notification_service = notification_service
  end

  def process_order(order)
    # Code to process the order
    @notification_service.send_notification("Order processed successfully")
  end
end

class NotificationService
  def send_notification(message)
    raise NotImplementedError, "Subclasses must implement this method"
  end
end

class EmailNotificationService < NotificationService
  def send_notification(message)
    # Code to send an email notification
  end
end

Here, OrderProcessor depends on an abstraction (NotificationService) rather than a concrete implementation. This allows easy replacement of notification methods without modifying OrderProcessor.

Conclusion

The Dependency Inversion Principle helps create more flexible and maintainable software by inverting dependencies. By ensuring that high-level modules depend on abstractions rather than concrete implementations, developers can build systems that are adaptable to change. The examples above illustrate how to refactor Ruby code to comply with DIP, making the design modular and reducing the impact of changes on high-level modules.

Software Engineering SOLID