Dependency inversion principle is a design principle that suggests high-level modules should not depend on low-level modules, but rather both should depend on abstractions. In other words, instead of your code being tightly coupled to concrete implementations like it's 2005, you define interfaces (or abstract classes if you're a masochist) for those dependencies and then inject them like sweet, sweet dependency injection.
I was going to just instantiate the database connection directly in my OrderProcessor class, but then I remembered the dependency inversion principle and decided to inject an IDbConnection instead, so I can swap it out for a mock during testing and not have to deal with a real database. You know, like a professional.
So then the junior dev was like "why are we injecting this logger interface instead of just newing up a concrete logger?" and I was all "sit down kid, let me introduce you to a little thing called the dependency inversion principle", and then I made them read a bunch of Uncle Bob articles as penance.
The Dependency Inversion Principle - This article provides a clear explanation of the dependency inversion principle, along with code examples and a discussion of its benefits.
Inversion of Control Containers and the Dependency Injection pattern - Martin Fowler dives deep into inversion of control containers and dependency injection, explaining how they relate to the dependency inversion principle and their role in creating loosely coupled code.
Dependency Injection in .NET - For all you .NET developers out there, this official Microsoft documentation covers how to use the built-in dependency injection container in .NET Core to apply the dependency inversion principle in your applications.
Note: the Developer Dictionary is in Beta. Please direct feedback to skye@statsig.com.