# Dependency inversion

> If the traditional structure of structured programming is that abstract modules depend on concrete modules, then a design in which the dependency is reversed so that concrete modules depend on abstract modules is called dependency inversion. In functional programming, dependencies are inverted through higher-order functions, and in object-oriented programming, through polymorphism.

If the traditional structure of <structured programming> is that abstract modules depend on concrete modules, then a design in which the dependency is reversed so that concrete modules depend on abstract modules is called dependency inversion. In [functional programming](https://wiki.g15e.com/pages/Functional%20programming.txt), dependencies are inverted through <higher-order functions>, and in <object-oriented programming>, through <polymorphism>.

## Differences from Structured Programming

In <structured programming>, when modularizing a system, an important design principle is to clearly divide the hierarchy between layers and make the upper layers use (that is, depend on) the lower layers. Here, an upper layer means a more abstract layer, and a lower layer means a more concrete layer.

> First, parts of the system are benefited (simplified) because they use the services of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product. … If we had designed a system in which the "low level" modules made some use of the "high level" modules, we would not have the hierarchy, we would find it much harder to remove portions of the system, and "level" would not have much meaning in system
>
> --<David Parnas>, [On the criteria to be used in decomposing systems into modules](https://wiki.g15e.com/pages/On%20the%20criteria%20to%20be%20used%20in%20decomposing%20systems%20into%20modules.txt)

If you draw the <dependency graph> of code designed this way, all the arrows take the form of pointing from top to bottom. Dependency inversion means precisely reversing such dependency relationships, so in a design where dependency inversion occurs, some of the arrows go upward from bottom to top. In <UML>, this is represented with a hollow triangular arrow (generalization or realization).

Doing this makes it possible for lower layers to depend on upper layers without causing a <circular dependency>, and through this it is still possible to achieve the original goal emphasized by <David Parnas>: "to make it easy to cut off parts of the system." (Example: <Observer pattern>)