public static int identity(int i){ return i; } is the smallest unit I can think of. Is it worth wrapping in an interface? Does that actually decouple?

A more sensible example might be Math.abs() - it might be worth wrapping that in an interface so that you can one day replace it with StrictMath.abs().

Coupling is not bad, and should not give you an uncomfortable feeling, unless it stops you from doing things or makes them difficult. If you *need* to use Math.abs() sometimes and StrictMath.abs() others, *then* decouple from the implementation. With a decent IDE or a decent programming language it’s trivial to make such a change. YAGNI

I think my only disagreement with your comment is that sometimes I see reduced flexibility as a good thing if it improves things along other axes. I see design as a multi-variable optimization problem and thus to me saying “X is bad” implies an absolutism that shuts off parts of the solution space, and I don’t like that.

But I’m also willing to concede that I don’t generally prefer that part of the solution space either and it’s a good rule of thumb to explore other parts first.

To me, no matter what the benefits there is still value in trying to reduce the coupling, because every bit of coupling means less flexibility. Sometimes you can’t, and often the coupling is necessary to achieve your goals - hence why I devoted a big chunk of my post to point out that there are lots of cases where even tighter coupling than the minimum achievable is worthwhile.

So our only disagreement is whether or not the fact that it’s sometimes necessary to increase coupling to get the maximum benefits means that the coupling isn’t bad or that it still is bad but is worth it. That’s mainly a matter of wording. I choose to see it as being bad because it reinforces that increased coupling always as a cost that you need to keep in mind.