What Is the Dependency Inversion Principle? Policy, Detail and Who Owns the Interface

Wed, 21 Oct 2026 00:05:00 +0000

A checkout that takes a payment has to call the payment provider: there is no way around that at run time. It does not follow that the checkout’s source code has to name the provider, import its SDK, or change when the provider changes its API. The dependency inversion principle is the rule that separates those two things. It asks which way the arrows between modules should point, and its answer is that the code holding the important decisions should not depend on the code holding the details; the details should depend on it. This is part five of a series on SOLID, after the single responsibility, open-closed, Liskov substitution and interface segregation principles, and it leads into inversion of control, the mechanism most programs use to put the principle into practice. This article explains what the principle says, where it came from, why the flow of control and the direction of a dependency can point opposite ways, why the abstraction has to belong to the code that uses it, and what is not worth inverting. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

Dependency Inversion Principle on Artur Rios Lab

What Is the Dependency Inversion Principle? Policy, Detail and Who Owns the Interface