I was reading SOLID principles on a website, in which for D - Dependency Inversion Principle it says:
“Depend on abstractions, not on concretions”
In other words. we should design our software in such a way that various modules can be separated from each other using an abstract layer to bind them together.
Dependency Inversion Principle Example
The classical use of this principle of bean configuration in the Spring framework.
In spring framework, all modules are provided as separate components which can work together by simply injected dependencies in other module. This dependency is managed externally in XML files.
These separate components are so well closed in their boundaries that we can use them in other software modules apart from spring with same ease. This has been achieved by dependency inversion and open closed principles. All modules expose the only abstraction which is useful in extending the functionality or plug-in in another module.
I have a few questions on it.
- Depend on abstractions, not on concretions It means, coding to interfaces, not to concrete classes?
- Why Spring bean example is given? Yes we can use interfaces to inject the dependency. But, we can also inject a concrete class?