Hacker News Reader

Comment by tonyarkles | Hacker News Reader

> 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.

View on HN

But 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.

For 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 :)

> 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.

No 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.

And 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.

> 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).

That'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.

It'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.

It’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.

Agreed, 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.

Yeah this is what I was thinking. I pity the people who navigate java projects without ctrl+alt+b. What an existence that must be.

I pity the people who navigate java projects.

> 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.

We just did a major reorg, and everyone who promoted that locked in tool got let go. There were other reasons for the reorg, but take this as a warning, if the tool you promote isn't productive you lose your job.

Without additional context, that seems a bit extreme. People often promote tools because they have some experience and have not (yet) had a poor experience with them.

These were senior technical architects that I doupt wrote more than a dozen lines of code in the tool, nothing real. They had great pie in the sky ideas, and the tools did useful things, but they forced everyone to use it for many years and kept defending it for years while evidence kept building up that using the tools made projects take 5 times longer than just writing in C.

If they had accepted the evidence and backed off the tool until it could deliver the better than C quality (which it did do) at the same speed of development they might still be around. However in the end we need to ship code to make money and our competitors were catching up on us which isn't acceptable to the business.

Let this be a lesson when you want to adopt new tools. They might be better but they might have some unexpected downside that means they are not useful.

A decade ago I was writing a big C# application using Ninject* DI framework and this is identical to my experience.

I 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.

Reply on news.ycombinator.com