SOLID principles
intermediateDependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend on abstractions.
The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. And abstractions should not depend on details — details should depend on abstractions. The "inversion" is in the direction of the source-code dependency: normally high-level policy code would reference the concrete low-level classes it uses, but DIP flips that so both sides point at an interface in the middle.
A wall switch doesn't know whether it's connected to a lightbulb, a fan, or a siren. It just toggles power. The switch defines what it needs; each device adapts to that contract.
Key Concepts
1
Concretely, a high-level OrderService that needs to save orders should not new a MySQLOrderRepository or import that concrete class. Instead it depends on an OrderRepository interface, and the MySQL implementation depends on that same interface by implementing it. Ownership of the abstraction conceptually belongs with the high-level module — it declares the contract it needs — and the low-level module conforms to it. The concrete implementation is then supplied from outside, which is where dependency injection comes in: a constructor takes an OrderRepository, and a framework like Spring (or plain wiring in main) decides at runtime whether that is the MySQL version, an in-memory fake, or a mock. Note that DIP (the principle) and dependency injection (a technique for supplying dependencies) are related but distinct, and conflating them is a common interview slip.
OrderServicenewMySQLOrderRepositoryOrderRepositorymain
2
The payoff is decoupling and testability. High-level business logic no longer drags a specific database, HTTP client, or message broker along with it, so you can swap implementations, defer infrastructure decisions, and — most valuably — test the policy in isolation by injecting a fake. The smell that signals a violation is business logic that constructs its own infrastructure with new or reaches for static singletons, which welds policy to a particular detail and makes the high-level code impossible to test without that real dependency present.
new