I don't understand how this is the case. If anything, an interface is MUCH easier to understand than a variety of functions strung together.
I mean, this is the whole reason we have APIs. If I'm a consumer, I would much rather read and understand the API and its contract than try to read through the code to find out requirements.
We are talking about a single function that possibly takes zero arguments versus an interface (TFA doesn't seem to show the code, but the interface presumably exists for DI).
I have waded through such code in Java, rather than C#. At least some of it is fighting the language; Java is pretty hostile to writing DI style code.
On top of that, even in languages that are more DI friendly, DI significantly decreases the lexical locality of code that is dynamically very close.
I don't think that you necessarily need lexical locality, rather you need specification. And interfaces are just an easy way to make a specification. The problem with "too much" lexical locality is that now you have to search DEEP into stacks to figure out what really going on.
The whole point of specifications is trying to extract the most requirements in the least amount of time. With more "top level" interfaces and tools like DI you can do that, but certainly you can take it too far. A single function, I'd say, is way too far.
I don't understand how this is the case. If anything, an interface is MUCH easier to understand than a variety of functions strung together.
I mean, this is the whole reason we have APIs. If I'm a consumer, I would much rather read and understand the API and its contract than try to read through the code to find out requirements.