4 ms·

Personally, when I build something, I prefer to know exactly what will happen prior to compile/build, not hope some configuration will handle things. I can dea

Personally, when I build something, I prefer to know exactly what will happen prior to compile/build, not hope some configuration will handle things. I can deal with both, but just a preference. In general, dynamic integrations like IoC, etc make things harder to troubleshoot/debug as well.

exabrial 9y ago
Exactly, right? That's what DI/IOC allows you to do. You can test a component where the variables always return simple deterministic results for one unit of code, or/[preferably] and you can also have a set of tests where you integrate all components.
- chris_wot 9y ago
  I think he's talking about autowiring.
  - dullgiulio 9y ago
    Exactly, and a lot of Spring discussions conflate the things and blurry the image a lot. Inversion of Control is really good and there are no reasons not to use it. When you have something that can be done in multiple ways, make a small interface and several implementations for it. The trick now is how to decide what to use. The simplest way is just to parse your configuration file or application flags/arguments in main and instantiate the concrete implementation of your classes there, then pass them down all the way until you need them. This is explicit, simple and clean. Spring makes you (at least) do two things wrong: 1. Configure the concrete implementations the wrong way. You don't want your users to decide which class implements a certain interface. You want them to decide something higher level, like for example "get crash data via e-mail" or "get crash data in logs". The rest is implementation details. 2. Annotations for autowiring: my feeling is that those are just to go around Java verboseness. Instead of typing "VeryLongName veryLongName = new VeryLongName()", "@autowire" it easier to type. I have always seen it misused (used for stuff that is not Inverted/Configurable) and it makes code more magic. Even worse, you are back at having classes pick their dependencies, even if they are interface implementations. If your classes take their dependencies as constructor parameters, everything is much more explicit.
    - jacques_chester 9y ago
      > If your classes take their dependencies as constructor parameters, everything is much more explicit. This is the guidance that Spring team members give, to the point that Spring now defaults to injecting constructors without annotations. I agree that field/setter autowiring is Satan's handicraft. Not all of this is Spring's fault. Java has the JavaBeans standard, which created a universe in which setter injection is common. JPA, for example, requires no-arg constructors. It makes me sad.
eeperson 9y ago
I agree. That is why I prefer to use compile time dependency injection like Macwire[1] or Dagger 2[2]. At least in the case of Macwire, it is super simple to reason about at compile time. [1] https://github.com/adamw/macwire https://github.com/adamw/macwire [2] https://google.github.io/dagger/ https://google.github.io/dagger/

exabrial 9y ago

Exactly, right? That's what DI/IOC allows you to do. You can test a component where the variables always return simple deterministic results for one unit of code, or/[preferably] and you can also have a set of tests where you integrate all components.

chris_wot 9y ago
I think he's talking about autowiring.
- dullgiulio 9y ago
  Exactly, and a lot of Spring discussions conflate the things and blurry the image a lot. Inversion of Control is really good and there are no reasons not to use it. When you have something that can be done in multiple ways, make a small interface and several implementations for it. The trick now is how to decide what to use. The simplest way is just to parse your configuration file or application flags/arguments in main and instantiate the concrete implementation of your classes there, then pass them down all the way until you need them. This is explicit, simple and clean. Spring makes you (at least) do two things wrong: 1. Configure the concrete implementations the wrong way. You don't want your users to decide which class implements a certain interface. You want them to decide something higher level, like for example "get crash data via e-mail" or "get crash data in logs". The rest is implementation details. 2. Annotations for autowiring: my feeling is that those are just to go around Java verboseness. Instead of typing "VeryLongName veryLongName = new VeryLongName()", "@autowire" it easier to type. I have always seen it misused (used for stuff that is not Inverted/Configurable) and it makes code more magic. Even worse, you are back at having classes pick their dependencies, even if they are interface implementations. If your classes take their dependencies as constructor parameters, everything is much more explicit.
  - jacques_chester 9y ago
    > If your classes take their dependencies as constructor parameters, everything is much more explicit. This is the guidance that Spring team members give, to the point that Spring now defaults to injecting constructors without annotations. I agree that field/setter autowiring is Satan's handicraft. Not all of this is Spring's fault. Java has the JavaBeans standard, which created a universe in which setter injection is common. JPA, for example, requires no-arg constructors. It makes me sad.

eeperson 9y ago

I agree. That is why I prefer to use compile time dependency injection like Macwire[1] or Dagger 2[2]. At least in the case of Macwire, it is super simple to reason about at compile time. [1] https://github.com/adamw/macwire https://github.com/adamw/macwire [2] https://google.github.io/dagger/ https://google.github.io/dagger/