Dependency inversion principle
(New page: The Dependency inversion principle states that high level modules should not depend on low level modules; both (high and low level) modules should depend on abstractions. It is common in ...) |
|||
| Line 7: | Line 7: | ||
As stated by Robert C. Martin: | As stated by Robert C. Martin: | ||
:''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."'' | :''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."'' | ||
| + | |||
| + | [[Image: Dependancy Inversion Principle.jpg]] | ||
Revision as of 03:43, 21 August 2008
The Dependency inversion principle states that high level modules should not depend on low level modules; both (high and low level) modules should depend on abstractions.
It is common in software development to write some low level modules that provide some useful functionality. These modules are then used by the high level modules. This means that the high level modules depend on the low level modules. The Dependency inversion principle states that both high and low level modules should depend on the same, general abstractions, thus inverting the dependency direction.
An advantage of this is that hard to simulate low level functions do not need to be written before high level functions are tested. This allows for a top-down approach for design and development.
As stated by Robert C. Martin:
- "High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."
