2025-02-20
2294
#web design
Samuel Olusola
97873
116
Feb 20, 2025 ⋅ 8 min read

Understanding the dependency inversion principle (DIP)

Samuel Olusola Software engineer (JS stack, GoLang incoming…) and student of computer science at the University of Lagos.

Recent posts:

Stop Writing REST APIs From Scratch in 2025

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.

Ikeh Akinyemi
Oct 14, 2025 ⋅ 3 min read
good dx is not enough component libraries featured image

Good DX isn’t enough: Why your component library still fails your team

Great developer experience feels amazing, until your design system starts breaking down. Here’s why good DX isn’t enough and what makes teams scale successfully.

Peter Aideloje
Oct 14, 2025 ⋅ 9 min read
react 19.2 what is new and what to expect

React 19.2 is here: Activity API, useEffectEvent, and more

Discover what’s new in React 19.2, which features long-awaited features like the Activity API and the useEffectEvent Hook.

David Omotayo
Oct 13, 2025 ⋅ 7 min read
ai dev tool power rankings

AI dev tool power rankings & comparison [Oct 2025]

Compare the top AI development tools and models of October September 2025. View updated rankings, feature breakdowns, and find the best fit for you.

Chizaram Ken
Oct 13, 2025 ⋅ 9 min read
View all posts

8 Replies to "Understanding the dependency inversion principle (DIP)"

  1. Hi, really nice article! A couple of typos in the code examples. You’re writing log.info instead of log.error when an exception occurs. Cheers!

    1. Thanks for the tip — would you mind pointing out the specific code blocks where the typos occur?

  2. A couple of problems with this principle. High level and low level is vaguely defined. If you apply this to the highest levels, this works fine. But the lower you go, the more this will feel the effects of an extra pointer to resolve or an extra function call. So, make sure that in your language, this results in, as much as possible, zero cost abstractions. Interfaces and Traits are typically fine, but watch out with proxies, abstract classes or any form of wrapper constructs.

Leave a Reply