4 ms·
"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 depen
by Ace17 9y 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 9y agoNot 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 9y agoYou 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).