5 ms·

I felt strongly enough about this topic to write a full blog post: http://sreque.blogspot.com/2019/08/the-autumn-manifesto-why-spring-is.html http://sreque.blog

by sreque 6y ago

I felt strongly enough about this topic to write a full blog post: http://sreque.blogspot.com/2019/08/the-autumn-manifesto-why-spring-is.html http://sreque.blogspot.com/2019/08/the-autumn-manifesto-why-.... TLDR: so-called DI frameworks are really just frameworks for creating and consuming global variables and have very little to do with the actual principle in of DI. That said, I think the jvm and java the language are in a great spot. It's the frameworks and community that need a shift in mindset.

lmm 6y ago
I disagree with that blog post. It may be technically possible to hijack the classloader mechanism to make instantiating classes do dependency injection, but it's not easy or idiomatic, and it's not good for maintainability either; a reader can't tell the difference between a global service and a value object if both are just "new Foo()". DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability. Autowiring mechanisms where you have some kind of global bag of (pseudo-singleton) services by type, and wire service dependencies implicitly by type rather than explicitly, are a legitimate tradeoff that's appropriate for some cases. Don't conflate Spring with Spring Boot. One is a framework that offers some legitimate value even if it makes some questionable tradeoffs; the other is a fractal of bad design.
- hderms 6y ago
  Which one is the fractal of bad design?
  - lmm 6y ago
    Spring Boot
- sreque 6y ago
  In response to: "DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability." You don't need a DI framework to do any of what you described. Also, I believe that what you are saying doesn't fundamentally describe DI, though it is related. In this post I go over what DI really means: https://sreque.blogspot.com/2019/09/dependency-injection-101.html https://sreque.blogspot.com/2019/09/dependency-injection-101... I have never seen a case where using autowiring forms a legitimate tradeoff; it has always resulted in worse, harder-to-maintain code with little benefit in return. I conflate Spring with Spring Boot because Spring Boot is built on Spring and most of my problems with Spring Boot apply equally to Spring.
  - lmm 6y ago
    Your blog post is, frankly, wrong. That's not what DI is usually used or understood to mean.
pjmlp 6y ago
The mindset that Java is often blamed for was already in full swing when other technologies ruled the enterprise. Architecture astronauts will produce the same designs regardless of the programming language.

by sreque 6y ago

lmm 6y ago

I disagree with that blog post. It may be technically possible to hijack the classloader mechanism to make instantiating classes do dependency injection, but it's not easy or idiomatic, and it's not good for maintainability either; a reader can't tell the difference between a global service and a value object if both are just "new Foo()". DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability. Autowiring mechanisms where you have some kind of global bag of (pseudo-singleton) services by type, and wire service dependencies implicitly by type rather than explicitly, are a legitimate tradeoff that's appropriate for some cases. Don't conflate Spring with Spring Boot. One is a framework that offers some legitimate value even if it makes some questionable tradeoffs; the other is a fractal of bad design.

hderms 6y ago
Which one is the fractal of bad design?
- lmm 6y ago
  Spring Boot
sreque 6y ago
In response to: "DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability." You don't need a DI framework to do any of what you described. Also, I believe that what you are saying doesn't fundamentally describe DI, though it is related. In this post I go over what DI really means: https://sreque.blogspot.com/2019/09/dependency-injection-101.html https://sreque.blogspot.com/2019/09/dependency-injection-101... I have never seen a case where using autowiring forms a legitimate tradeoff; it has always resulted in worse, harder-to-maintain code with little benefit in return. I conflate Spring with Spring Boot because Spring Boot is built on Spring and most of my problems with Spring Boot apply equally to Spring.
- lmm 6y ago
  Your blog post is, frankly, wrong. That's not what DI is usually used or understood to mean.

pjmlp 6y ago

The mindset that Java is often blamed for was already in full swing when other technologies ruled the enterprise. Architecture astronauts will produce the same designs regardless of the programming language.