3 ms·

"If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.". It all boils do

by ane 11y ago

"If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.". It all boils down to this. Here's the catch, though: with dependencies, it is really, really hard to know whether dependency implementations change or not. What is more, in most languages, implementing dependency injection is so trivial that it is always worth it. Conversely, the work associated with changing implementations that aren't built with some form of loose coupling, that is, designing around DI, is in most cases non-trivial.

jblow 11y ago
Nope. Nope nope. This is the same argument that early OO people used to justify the idea that you should use getter/setters everywhere rather than directly accessing your variables. You never know if the implementations of those ideas will change!!!!!11 That's programming. It is always possible that anything might need to change. That is how it is. This does not justify calcifying your code by adding extra unnecessary structure, because what that in fact does is make the program harder to change later (while requiring you to do more work up front). Also, as the author of the article notes, it requires one to keep more pieces of information clear in one's head in order to work with code of equivalent complexity, something that is almost always a big lose. In a good language, if a dependency implementation changes, you know this because your program does not compile. (Well, of course because you are not a noob, you are linking things that are versioned in the first place, so this should not ever even be an issue unless you are actively upgrading outside code and are expecting it.) When your program does not compile, you want the compile error to be at the site that uses the dependency, because that tells you exactly where the thing is that you need to fix. Adding excess verbiage around it, and distancing the site that instantiates the dependency from the site that uses it, only causes more work. If you are using a language/system that doesn't allow you to program this directly and clearly, then maybe that is the problem...
- ane 11y ago
  It seems to me that you think designing for DI is much more complicated than it actually is. In most modern languages it is trivial to implement. Especially if you have ad-hoc polymorphism available, it comes at virtually no price. Some languages make it more difficult than others, but in most modern languages it's really easy. Your example of getters and setters is a bit of a red herring. I understand what you mean by it, but it doesn't apply in this case. This is because the getter and setter is an abstraction that derives from encapsulation. But it is also an antipattern. In many cases, getters and setters are just a type of needless complexity--a distraction, overengineering! On the other hand, DI solves a real, practial problem, and if your language is intelligent, it is really simple to implement.

by ane 11y ago

jblow 11y ago

Nope. Nope nope. This is the same argument that early OO people used to justify the idea that you should use getter/setters everywhere rather than directly accessing your variables. You never know if the implementations of those ideas will change!!!!!11 That's programming. It is always possible that anything might need to change. That is how it is. This does not justify calcifying your code by adding extra unnecessary structure, because what that in fact does is make the program harder to change later (while requiring you to do more work up front). Also, as the author of the article notes, it requires one to keep more pieces of information clear in one's head in order to work with code of equivalent complexity, something that is almost always a big lose. In a good language, if a dependency implementation changes, you know this because your program does not compile. (Well, of course because you are not a noob, you are linking things that are versioned in the first place, so this should not ever even be an issue unless you are actively upgrading outside code and are expecting it.) When your program does not compile, you want the compile error to be at the site that uses the dependency, because that tells you exactly where the thing is that you need to fix. Adding excess verbiage around it, and distancing the site that instantiates the dependency from the site that uses it, only causes more work. If you are using a language/system that doesn't allow you to program this directly and clearly, then maybe that is the problem...

ane 11y ago
It seems to me that you think designing for DI is much more complicated than it actually is. In most modern languages it is trivial to implement. Especially if you have ad-hoc polymorphism available, it comes at virtually no price. Some languages make it more difficult than others, but in most modern languages it's really easy. Your example of getters and setters is a bit of a red herring. I understand what you mean by it, but it doesn't apply in this case. This is because the getter and setter is an abstraction that derives from encapsulation. But it is also an antipattern. In many cases, getters and setters are just a type of needless complexity--a distraction, overengineering! On the other hand, DI solves a real, practial problem, and if your language is intelligent, it is really simple to implement.