4 ms·
They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in
by troels 11y ago
They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.
- emsy 11y agoDI is not an "800 lb gorilla". If anything, certain implementations of DI frameworks are (I'm looking at you, Spring).
- troels 11y agoI disagree. They were a solution to the inflexibility of rigid languages like Java, but seems entirely alien in the context of Javascript. A DI framework adds a load of indirection.
- brodo 11y agoDI is a design principle, not a class for frameworks. DI just means to "inject" the dependancies of an object through constructor arguments, setters or by simply setting instance (aka member) variables. In other words, DI means that you don't use global variables (aka singletons). DI does not provide any more flexibility itself, but most DI frameworks encourage the usage of interfaces instead of concrete classes (which is a good thing) when it comes to defining dependancies. Sadly however, the fancy pants therm for using interfaces is "dependency inversion", because when using interfaces, the compile time and runtime dependancies of a class point in opposite directions. As you can imagine, this lead to a lot of confusion.
- radicalbyte 11y agoIt has nothing to do with the "rigidity" of Java, and everything to do with the complexity of the problems solved in Java land. The value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
- trumbitta2 11y agoI like Angular's DI. It makes it easy – to me, but YMMV - to organize my thoughts and my code.
- troels 11y agoFair enough. It's probably a matter of taste to some extend. I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
- JustSomeNobody 11y agoToo many people reach for DI first where some quiet time with a pencil and paper could produce a much better design that doesn't need a DI framework.
- aikah 11y ago> They kind of solve the same problem no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.
- troels 11y agoIoC is the way that DI solves the problem. But the problem is dependency management - and there are other ways around that.
- stupidcar 11y agoThe difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.
- mercurial 11y agoDependency injection has merit in any language. Throw DI out of the window, testability goes with it. Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).