Python programmers don’t use Dependency Inversion (DI) enough. There are a number of reasons why not:
- It’s tricky — it inverts certain intuitive understandings of code flow.
- Sometimes people do dependency injection and think they’ve done Dependency Inversion.
- The benefits of DI are easily visible in mature codebases, but implementing DI in new code adds a level of abstraction that many programmers feel is cumbersome. It gets YAGN I’d, when it shouldn’t.
But dependency Inversion DI could save the code you’re writing today from being obsolete in 2 years.
What’s more, Python has a fantastic native feature called Entry Points (supported by most packaging tools) that allows you to get a lot of extensibility out of Dependency Inversion, easily.
So here’s what I plan to cover in this post:
- What is Dependency Inversion (and what does it look like in Python)?
- What are Python Entry Points?
- How Do These Two Things Go Together?
If you’re a Dependency Inversion Champ and feel like you have a SOLID handle on the concept (get it?), feel free to skim down to the Entry Points section.
What is Dependency Inversion?
Definitions
There’s a standard definition of the Dependency Inversion principle. It’s absolutely correct, but when you’re first learning about DI, it feels cryptic. Lets get it out of the way: