3 ms·

You're talking from the perspective of Java, which has been designed from the ground up with dependency injection in mind. Dependency injection is the inversio

by ffsm8 1y ago

You're talking from the perspective of Java, which has been designed from the ground up with dependency injection in mind. Dependency injection is the inversion of control pattern at the heart, which is something like oxygen to a Java dev. In other languages, these issues are solved differently. From my perspective as someone whoes day job has been roughly 60+% Java for over 10 yrs now... I think I agree with the central message of the article. Unless you're currently in Java world, you're probably better off without it. These patterns work and will on paper reduce complexity - but if comes at the cost of a massively increased mental overhead if you actually need to address a bug that touches more then a miniscule amount of code. /Edit: and I'd like to mention that the article actually only dislikes the frameworks, not the pattern itself

mattmanser 1y ago
DI wasn't around when Java (or .Net) came out. DI is a fairly new thing too, relatively speaking, like after ORMs and anonymous methods. Like after Java 7 I think. Or maybe 8? Not a Java person myself. I know in .net, it was only really the switch to .net core where it became an integral part of the frameworks. In MVC 5 you had to add a third party DI container. So how can it have been designed for it from the ground up? In fact, if you're saying 10 years, that's roughly when DI became popular. You're wrong about other languages not needing it, yes statically typed languagess need it for unit testing, but you don't seem to realize that from a practical perspective DI solves a lot of the problems around request lifetimes too. And from an architectural context it solves a lot of the problem of how to stop bad developers overly coupling their services. Before DI people often used static methods, so you'd have a real mess of heavily interdependent services. It can still happen now but.its nowhere near as bad as the mess of programming in the 2000s. DI helped reduce coupling and spaghetti code. DI also forces you to 'declare' your dependencies, so it's easy to see when a class has got out of control. Edit: I could keep on adding, but one final thing. Java and .Net are actually quite cumbersome to use DI, and Go is actually easier. Because Go has implicit interfaces, but older languages don't and it would really help reduce boiler plate DI code. A lot of interfaces in Java/C# only exist to allow DI tow work, and are otherwise a pointless waste of time/code.
- ollysb 1y ago
  The Spring framework was released in 2003 when Java was at v1.4. From memory it wasn't the first DI framework either.
  - layer8 1y ago
    The term was coined in 2004: https://www.martinfowler.com/articles/injection.html https://www.martinfowler.com/articles/injection.html It’s not correct that Java was designed for it, unless you want to call class loading dependency injection. It’s merely that Java’s reflection mechanism happened to enable DI frameworks. The earlier Java concept was service locaters (also discussed in the article linked above).
deleted 1y ago
[deleted]

by ffsm8 1y ago

mattmanser 1y ago

DI wasn't around when Java (or .Net) came out. DI is a fairly new thing too, relatively speaking, like after ORMs and anonymous methods. Like after Java 7 I think. Or maybe 8? Not a Java person myself. I know in .net, it was only really the switch to .net core where it became an integral part of the frameworks. In MVC 5 you had to add a third party DI container. So how can it have been designed for it from the ground up? In fact, if you're saying 10 years, that's roughly when DI became popular. You're wrong about other languages not needing it, yes statically typed languagess need it for unit testing, but you don't seem to realize that from a practical perspective DI solves a lot of the problems around request lifetimes too. And from an architectural context it solves a lot of the problem of how to stop bad developers overly coupling their services. Before DI people often used static methods, so you'd have a real mess of heavily interdependent services. It can still happen now but.its nowhere near as bad as the mess of programming in the 2000s. DI helped reduce coupling and spaghetti code. DI also forces you to 'declare' your dependencies, so it's easy to see when a class has got out of control. Edit: I could keep on adding, but one final thing. Java and .Net are actually quite cumbersome to use DI, and Go is actually easier. Because Go has implicit interfaces, but older languages don't and it would really help reduce boiler plate DI code. A lot of interfaces in Java/C# only exist to allow DI tow work, and are otherwise a pointless waste of time/code.

ollysb 1y ago
The Spring framework was released in 2003 when Java was at v1.4. From memory it wasn't the first DI framework either.
- layer8 1y ago
  The term was coined in 2004: https://www.martinfowler.com/articles/injection.html https://www.martinfowler.com/articles/injection.html It’s not correct that Java was designed for it, unless you want to call class loading dependency injection. It’s merely that Java’s reflection mechanism happened to enable DI frameworks. The earlier Java concept was service locaters (also discussed in the article linked above).

deleted 1y ago

[deleted]