3 ms·
> Java has a culture of over-engineering [which] Go successfully jettisoned [looks at the code bases of several recent jobs] [shakes head in violent disagreeme
by zimpenfish 3y ago
> Java has a culture of over-engineering [which] Go successfully jettisoned
[looks at the code bases of several recent jobs]
[shakes head in violent disagreement]
If I'm having to open 6-8 different files just to follow what a HTTP handler does because it calls into an interface which calls into an interface which calls into an interface (and there's no possibility that any of these will ever have a different implementation) ... I think we're firmly into over-engineering territory.
(Anecdata, obviously)
- grumpyprole 3y agoI stand corrected!
- bb88 3y agoBut don't those exist primarily for unit testing? That was my understanding of why interfaces were there. If you wanted a mock, you needed an interface, even if there would ever only be one implementation of it in production.
- tormeh 3y agoI hate this pattern. Needless indirection for insignificant benefit.
- bb88 3y agoGolang "punishes" you for wanting to write a unit test around code. You need to refactor it to use an interface just to unit test it.
- sidlls 3y agoNo, you don’t, unless you’re of the opinion that actual data structures with test data should not be used in a unit test.
- bb88 3y agoI think you're missing the point here. Duck typing with python (e.g.) makes it easy to mock a class. One can subclass a Java class to make a mock, etc. One can't do that in golang unless it's through an interface which then decouples tightly coupled code because [golang reasons].
- akoboldfrying 3y agoIt's indeed horrible when debugging. OTOH, there's merit to the idea that better testing means less overall time spent (on either testing or debugging), so design choices that make testing easier provide a gain -- provided that good tests are actually implemented.
- zimpenfish 3y ago> But don't those exist primarily for unit testing? I believe that's why people insert them everywhere, yes, but in the codebases I'm talking about, many (I'd say the majority, to be honest) of the interfaces aren't used for testing because they've just been cargo-culted rather than actually considered. (Obviously this is with hindsight - they may well have been considered at the time but the end result doesn't reflect that.)
- dharmab 3y agoWhy would those require 6 separate files?
- theshrike79 3y agoInterface, actual implementation, Factory, FactoryImpl, you get the idea. Java lends itself to over-engineering more than most languages. Especially since it seems that every project has that one committer who must be getting paid per line and creates the most complex structures for stuff that should've been a single static function.
- zimpenfish 3y agoThey don't; you could put it all in one file but people tend to separate interfaces from implementation from types from ...
- evantbyrne 3y agoJava is a beautiful and capable language. I have written ORMs in both Java and Go, and the former was much easier to implement. Java has a culture problem though where developers seem to somehow enjoy discovering new ways to complicate their codebases. Beans are injected into codebases in waves like artillery at the Somme. Errors become inscrutable requiring breakpoints in an IDE to determine origin. What you describe with debugging a HTTP handler in your Go project is the norm in every commercial Java project I have ever contributed to. It's a real shame that you are seeing these same kinds of issues in Go codebases.
- davedx 3y agoAgree. Open source OAuth go libraries have this too. It's like working with C++ code from the bad old days when everyone thought inheritance was the primary abstraction tool to use.