SOLID Principles • Dependency Inversion PrincipleEasy⏱️ ~2 min
What is Dependency Inversion Principle (DIP)?
Definition
Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces). Additionally, abstractions should not depend on details. Details should depend on abstractions.
This principle inverts the traditional dependency direction where high-level business logic directly depends on low-level implementation details. Instead, both layers depend on a shared abstraction layer.
Core Problems DIP Solves:
First, it eliminates tight coupling between business logic and implementation details. When
Second, it enables testing. High-level modules that depend on abstractions can use mock implementations during testing without modifying production code.
Third, it supports extensibility. New implementations can be added by implementing the abstraction interface without changing existing high-level code.
PaymentProcessor directly creates MySQLDatabase objects, changing databases requires modifying business logic.Second, it enables testing. High-level modules that depend on abstractions can use mock implementations during testing without modifying production code.
Third, it supports extensibility. New implementations can be added by implementing the abstraction interface without changing existing high-level code.
Interview Tip: Emphasize that DIP is about dependency direction, not just using interfaces. The key insight is that both layers depend on abstractions owned by the high-level module.
Real-World Analogy: An electrical appliance depends on the standard power socket interface, not on the specific power plant generating electricity. Both the appliance (high-level) and the power infrastructure (low-level) depend on the socket abstraction. You can plug the same appliance into different power grids worldwide with an adapter.
💡 Key Takeaways
✓High-level modules define abstractions that low-level modules implement
✓Dependency direction flows toward abstractions, not concrete implementations
✓Abstractions should be stable and owned by the high-level policy layer
✓Both layers become independently changeable when properly decoupled
✓Testing becomes feasible through substitutable implementations
📌 Examples
1Payment processor depending on PaymentGateway interface instead of concrete StripeGateway
2Notification service depending on MessageSender interface instead of EmailClient
3Report generator depending on DataSource interface instead of MySQLConnection