Understanding SOLID Principles: Dependency Inversion | Hacker News Reader

Understanding SOLID Principles: Dependency Inversion

dev.to

42 pointsrbanffy7 comments

"The drawback of dependency Inversion is that you need a dependency injection container, and you need to configure it."

This is simply wrong.

You can do dependency injection without a container (using factories, or link-time polymorphism).

Dependency inversion is a lot more general:

Depending on a header file (interface) instead of a specific implementation already is a kind of dependency inversion.

Having a language-independent IR in a compiler also counts as dependency inversion (compared to an implementation where the frontend calls the backend): it prevents dependencies between the frontend and the backend (whose reasons to change generally aren't correlated), by making everybody depend on the IR instead.

Not only is it wrong, but it's wildly misleading about why dependency inversion is desirable. This article is trash; it's basically a copy/paste of the Wikipedia entry on dependency inversion, rewritten awkwardly (not to mention the usage of Comic Sans).

You can even do it(in fact it's a common pattern) using partial application. Configure a function by binding its first argument with some config data/behavior/policy/mock etc. This eliminates the first arg of the function signature and generalizes it. Then pass that function off to another higher-order function. The advantage is the consuming function is isolated and knows nothing about the composed behavior - even during construction.

In this case the function signature corresponds to the class interface, and partial application corresponds with binding the injected dependencies passed via the constructor (using a factory, or dependency injection container etc).

My problem with blog posts on SOLID (like this one) is they overcomplicate ideas that should be simple. This entire article could be replaced with:

- When trying to make code testable, it's easier to configure from the outside than inside.

There's no need to mention other topics like factories, DI containers, etc. All of those are obvious abstractions on top of the very simple idea.

They are only obvious after you see them.

My only criticism is about articles that confuse the principle with the means you use to obtain it. Yes, do talk about factories and containers, but separate them from the principle and keep in mind that there are many other ways to get it. You don't need a DI container.

Besides, it only provides you an specific kind of testability, that may or may not be the best way to test your code.

Dependency Inversion ≠ Dependency Injection

There's also "Dependency Rejection" http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to...

Reply on news.ycombinator.com