Understanding SOLID Principles: Dependency Inversion

https://dev.to/theodesp/understanding-solid-principles-dependency-injection

by rbanffy • 9 years ago

42 7 9 years ago

trevor-e• 9 years ago

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.

marcosdumay• 9 years ago

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.

danbruc• 9 years ago

Dependency Inversion ≠ Dependency Injection

Ace17• 9 years ago

"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.

rmaus• 9 years ago

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).

julian_1• 9 years ago

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).

u801e• 9 years ago

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

Understanding SOLID Principles: Dependency Inversion

Related Stories