Comment by iainmerrick | Hacker News Reader

Comment by iainmerrick | Hacker News Reader

This is good advice and a good writeup, but I take exception to one (boldface!) line:

Coupling kills software

I hear this a lot but I think it’s highly overstated.

The “clear” final version is still strongly coupled -- you can’t call find_definition without it directly calling the build_url helper! The key aspect isn’t the coupling, it’s that the high-level imperative function is calling a simple, low-level, testable helper.

Coupling can be bad, sure, but not if it’s kept under control. And excessive decoupling can make programs much harder to understand and debug! Have you ever worked on an app where every reference to another object is injected via a DI framework, and where all the significant calls that actually do stuff are farmed out to asynchronous messages and callbacks, all in the name of decoupling and testability? That can make it really hard to debug problems. A good balance is what’s needed, not decoupling over all other concerns.

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

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.

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.

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.

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.

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

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.

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

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

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

This is a common misconception about "coupling". Decoupling is making something truly independent, not making the dependency injectable. Making it injectable is the last resort when you can't make it independent.

The real thing you should be thinking of is, look at those libraries and their documentation / READMEs (depending on library size, smaller actually preferred). Can I make my code modules more like that? Will the API boundaries I define make sense?

> Coupling kills software

> I hear this a lot but I think it’s highly overstated.

Coupling is like trying to get to your destination by swimming through molasses – each move you make impacts atoms far away from you because they are tightly bound to the ones near you, and those atoms exert a force back.

Reply on news.ycombinator.com