3 ms·

I have a common personal use-case for inheritance: If I'm forced to use a framework that infects my whole codebase, e.g. Spring, it's often possible to escape

by mrkeen 4y ago

I have a common personal use-case for inheritance: If I'm forced to use a framework that infects my whole codebase, e.g. Spring, it's often possible to escape the infection by splitting a Service into a SpringService and a LogicService. LogicService thereby remains testable and doesn't depend on Spring. The way to connect them is to have the SpringService inherit from the non-spring service. That said, I'd rather have neither Spring nor inheritance.

coutego 4y ago
It's funny how times have changed. Spring used to be that (micro)framework that prevented your code to depend on anything framework related. And here we are now... I have been avoiding inheritance like the plague since at least 15 years ago and enjoying the pleasure of working with Spring for the same amount of time, approximately. But nowadays looking at what people do with Spring makes me extremely sad. Every time I find people "injecting" things by using annotations I can just think "WFT? Haven't we learnt /anything/?"
- mrkeen 4y ago
  No, nothing's changed. Spring still infects your whole codebase. Just look at the imports, or try to run your code via a different framework if you think I'm exaggerating. Its proponents still make the same claims about it protecting you from coupling, not causing it.
  - coutego 4y ago
    Spring does not need to infect your codebase. You can use the container without importing anything from Spring in other than one class (the one bootstrapping the system). If you want to use Spring classes in the implementation of your clases then yes, you will need to import them. But this is no different than any other library. If you just use XML configuration files (or use @Configuration) you don't (shouldn't) use @Inject, @Autowire and all other abominations. Or at least you didn't need, last time I checked a couple years ago. All your code is clear, free of any Spring code (unless you use some of the libraries) and fully reusable, testable, etc. Why everyone moved to annotations for "dependency injection" (that crap is NOT DI!!!!!), not only in Java, but Python, Typescript, etc. I just can't understand. It can't only be the convenience of doing so by saving some keystrokes, but I just can't get it. We solved the modularity beautifully with Spring (and other DI engines) and then we proceed to throw away the solution and recreate the problem again? Get off my lawn...
oweiler 4y ago
If you use constructor injection services are unit testable without touching Spring.
- mrkeen 4y ago
  Then can I remove those imports?
  - _boffin_ 4y ago
    Mock the dependencies in the constructor and test. Why are you talking about removing imports?
    - mrkeen 4y ago
      I do use constructors. I'm refuting the claim that my unit tests won't touch Spring. If my unit tests don't touch the Spring stuff in my class, either my unit tests on that class are woefully incomplete, or I didn't need the (explicit, directly-coupled) Spring stuff in my class.

by mrkeen 4y ago

coutego 4y ago

It's funny how times have changed. Spring used to be that (micro)framework that prevented your code to depend on anything framework related. And here we are now... I have been avoiding inheritance like the plague since at least 15 years ago and enjoying the pleasure of working with Spring for the same amount of time, approximately. But nowadays looking at what people do with Spring makes me extremely sad. Every time I find people "injecting" things by using annotations I can just think "WFT? Haven't we learnt /anything/?"

mrkeen 4y ago
No, nothing's changed. Spring still infects your whole codebase. Just look at the imports, or try to run your code via a different framework if you think I'm exaggerating. Its proponents still make the same claims about it protecting you from coupling, not causing it.
- coutego 4y ago
  Spring does not need to infect your codebase. You can use the container without importing anything from Spring in other than one class (the one bootstrapping the system). If you want to use Spring classes in the implementation of your clases then yes, you will need to import them. But this is no different than any other library. If you just use XML configuration files (or use @Configuration) you don't (shouldn't) use @Inject, @Autowire and all other abominations. Or at least you didn't need, last time I checked a couple years ago. All your code is clear, free of any Spring code (unless you use some of the libraries) and fully reusable, testable, etc. Why everyone moved to annotations for "dependency injection" (that crap is NOT DI!!!!!), not only in Java, but Python, Typescript, etc. I just can't understand. It can't only be the convenience of doing so by saving some keystrokes, but I just can't get it. We solved the modularity beautifully with Spring (and other DI engines) and then we proceed to throw away the solution and recreate the problem again? Get off my lawn...

oweiler 4y ago

If you use constructor injection services are unit testable without touching Spring.

mrkeen 4y ago
Then can I remove those imports?
- _boffin_ 4y ago
  Mock the dependencies in the constructor and test. Why are you talking about removing imports?
  - mrkeen 4y ago
    I do use constructors. I'm refuting the claim that my unit tests won't touch Spring. If my unit tests don't touch the Spring stuff in my class, either my unit tests on that class are woefully incomplete, or I didn't need the (explicit, directly-coupled) Spring stuff in my class.