What does "dependency inversion principle" mean in OOP?

Question

What is meant by the "dependency inversion principle" in object-oriented programming? What does it do?

Answer 1

In object-oriented programming,
the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (e.g. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details.

The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

Source

Answer 2

The main reason for using dependency inversion is to allow for different implementations of those lower-level modules to be selected either at compile-time in the application or at runtime by configuration. This is a big win for testing because it allows you to completely isolate the code being tested and use mock objects.

Another way this is a huge help is for client deployments. Let's say you have different customers with different auth systems, or different databases, or reporting systems, or whatever. You can configure their system at deployment time by changing an XML file to choose the right implementations of those components to load, with no code changes at all.