Dependency inversion principle
m |
|||
| Line 5: | Line 5: | ||
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. | 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 | + | As stated by [[Bob 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]] | [[Image: Dependancy Inversion Principle.jpg]] | ||
Revision as of 02:06, 24 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 Bob 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."
