5 ms·
> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant east
by tonyarkles 6y ago
> every reference to another object is injected via a DI framework
And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.
- PaulKeeble 6y agoBut then despite that the class is getting a generated proxy that does basically nothing or is causing the problem and it is really hard to determine anything except tracing it at runtime to find out what actually is being run. People do some crazy things with Spring and interface injections in Java and it can get really Opaque quickly but also often it really is just 1 class implementing an interface and there are no tests using the interface at all.
- tonyarkles 6y agoFor the one project I worked on that was Spring-based, my joke was that Spring was a really effective way to convert compile-time errors into run-time errors :)
- Pet_Ant 6y ago> Spring was a really effective way to convert compile-time errors into run-time errors :) This is not a joke. Spring invalidates refactoring tools and a lot of static analysis. It makes working on Java feel like you are working on Python or something. The traceability of errors is very low. You can limit yourself to a subset of Spring's functionality (eg no component scanning, wiring up the beans manually) but it will not be idiomatic.
- arcbyte 6y agoAnd now you're into the Liskov substitution principle. All of your implementations should honor the same contract even if they do it in different ways.
- eweise 6y agoNo need to create interfaces generally in spring when there will only be one class implementing. For testing, mocks can be created directly from the actual classes.
- forest_dweller 6y agoI agree sometimes it can be an hunt if someone used some crazy implementation of the strategy pattern. However if you are following SOLID you shouldn't depend on a concrete class. I'm dealing with a project at the moment where they haven't done DI and everything is dependant on concret classes and I just can't write tests (without huge setup methods) for anything non-trivial and I have these large constructors initialising things in every class.
- boredumb 6y agoA decade ago I was writing a big C# application using Ninject* DI framework and this is identical to my experience.
- scaladev 6y agoIt's not a problem if you're using a proper IDE. Rider and IDEA will take you right to the implementation (or will display a list if there are multiple implementations) on Ctrl+Alt+B. This works on any of the parent classes/interfaces, or any inherited field or method.
- humbleMouse 6y agoYeah this is what I was thinking. I pity the people who navigate java projects without ctrl+alt+b. What an existence that must be.
- tasuki 6y agoI pity the people who navigate java projects.
- acdha 6y agoIt’s less of a problem but it’s still a problem because it forces people to have to keep more context in addition to what they’re really working on. Even experienced developers with the latest IDEs are slowed down when the culture encourages layers of gratuitous complexity, and the gains offered by advanced tooling are often cancelled out by people seeing that tooling as reducing the counter pressure against adding more.
- iainmerrick 6y agoAgreed, it’s not an insurmountable problem, but it’s still a hassle that gets in the way. Something that should be one click becomes 2 or 3 clicks and only works 85% of the time. For example, there might be one real implementation and one (or more) test stubs and that slows you down.
- carapace 6y ago> It's not a problem if you're using a proper IDE. From another POV it's IDE vendor lock-in: make the basic programming exercise so challenging that the users have to buy your special tool to even attempt it.
- nwsm 6y ago> only to eventually discover that there's only one class that implements that interface I mean, in this case it's literally: * right click on "someInjectedService" * select "Go To Implementations" and you'll be there. Generally I do relate to the complaint though. DI makes your project feel like a "system" as opposed to a "program" (not that this is a bad thing or unnecessary).
- tonyarkles 6y agoThat's the simple case. When it's a big chain of injected dependencies and you have to untangle the whole thing, it gets annoying quickly.