←back to thread

294 points NotPractical | 1 comments | | HN request time: 0s | source
Show context
xnorswap ◴[] No.41856752[source]
> Redbox.HAL.Configuration

> .ConfigurationFileService implements IConfigurationFileService

> STOP MAKING SERVICES AND FACTORIES AND INTERFACES AND JUST READ THE FUCKING

> JSON FILE YOU ENTERPRISE FUCKERS

I know it's cool to "hate" on OO, but "just read the fucking file" doesn't work if you want to run your unit tests without reading a fucking file.

It makes sense to abstract configuration behind an interface so you can easily mock it our or implement it differently for unit testing.

Perhaps you also want to have some services configured through a database instead.

This isn't a ConfigurationFileServiceFactoryFactory.

replies(12): >>41856822 #>>41856831 #>>41856836 #>>41856965 #>>41857895 #>>41858054 #>>41859117 #>>41859509 #>>41859750 #>>41859882 #>>41860221 #>>41864182 #
aidenn0 ◴[] No.41859882[source]
If you need to make your code more baroque and harder to understand in order to unit-test it, that seems like the tail wagging the dog.
replies(2): >>41860371 #>>41864272 #
consteval ◴[] No.41864272[source]
> more baroque and harder to understand

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.

replies(1): >>41871799 #
aidenn0 ◴[] No.41871799[source]
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.

replies(1): >>41882592 #
1. consteval ◴[] No.41882592[source]
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.