60

I don't get it
My brain does not have the capacity to understand it

How the fuck does my colleague manage to write 12 classes/interfaces for something so stupidly simple??

Two classes, a hand full of functions, done.

Why do you need this level of abstraction?
To mock the interfaces in unit tests? The unit tests you didn't write because "they're not necessary"?

No one will be able to understand this clusterfuck of a module even though it's entire purpose is "read number and write number elsewhere"...

Comments
  • 26
    God yes.

    I think these people are the reason people mock and hate OOP. Because we get fucks like this, that make 12 classes for something retartedly simple...

    3 of those are usually already part of some library already in the project, 2 more are Utility classes that also already exist somewhere else, 4 or just DTOs that literally contain 1 or two parameters and could be replaced by something like a Tuple or a map.

    You could refactor those 12 to actual 1 or 3 that would actually make sense both semantically and within their domain but you can't now, because everything is dependent on everything and nothing is doing solely it's job

    When you write some fucking code think about it in terms of responsibilities, domains and models, don't just slap classes on every new functionality, and for the love of god, please invest the 15 minutes into looking if the thing you're writing doesn't already exist in the project!
  • 11
    Rube Goldberg code I think is caused by one of 2 things

    1. They lack understanding of coding or the project so they can’t simplify the solution. They can only get there by adding things in until it works.

    2. They are paid by the hour and hopes no one notices.

    When I run into this, I look at the sign on my wall “maybe swearing will help.”
  • 9
    Some people just have too much class.
  • 1
    > No one will be able to understand this clusterfuck of a module even though it's entire purpose is "read number and write number elsewhere"...

    This just sounds like you could put this in the same class, easy as that. Maybe it's something caused by being in "TDD" mode or something, but that sounds a little outrageous. Though I'd probably do the same for an hour, spend an extra two figuring out what's wrong, write it all over again in a single class or method, and boom, it works.
  • 2
    I remember doing this, to make the module "testable". The actual code was such a mess and I couldn't even see that from the bubble I was in. Now I don't ever wanna write code that's complex / not-simple
  • 2
    I don't think he has any bad intentions of "let me sink more hours into this so I don't have to do anything else", I think the genuinely sees some benefit to the design.

    @marquiskurt I wasn't joking when I said two classes and a few functions, I alread had it planned out in my head...
  • 3
    @molaram yeah, I think it's absolutely beautiful
  • 3
    @Demolishun
    "Some are afraid of greatness" - Noble AI, The Dark Mod.
  • 2
    Don’t forget to make an interface for every class so that it can be used with dependency injection! Yes! Every class needs dependency injection! Even DTOs! And the mappers for the different kinds of DTOs! Everything! Dependency injection!!
    🤡
  • 0
    @Lensflare Is dependency injection the same as RAII? I guess, what is it?
  • 2
    @Demolishun no, DI is just the idea that objects that need other objects as dependencies, shouldn’t create those objects themselves. Instead, the dependencies should be injected. There are different ways to inject.
    The most simple and straightforward way is to just pass the dependency as a parameter in the constructor.
    But there are more sophisticated ways and whole frameworks around that concept.
    The extreme shit that I was referring to, is when the code uses a DI framework where you have a central spot to define what interface binds to what class and then dependencies are injected automatically whenever that interface is encountered.
    Devs are applying this everywhere brainlessly because “DI is good”.

    BTW, DI is a way to implement IoC, but the terms are being used interchangeably by the braindead devs.
  • 3
    Ohh good yeees I relate to the complexity for complexitys sake. I have a colleague that have on several occasions wrote functions like:

    CallWrite(text)
    {
    Write(text)
    }

    And no write is NOT a private function in this scenario so there is absolutley NO reason why write could not have been called from where CallWrite is called. How the hell do you even come up with this shit?
  • 0
    @G4nin0 ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
  • 0
    What does said clusterfuck actually do ?
  • 0
    @YouAllSuck monitor some hardware sensors (temperatures and such)
    And publish that data at a fixed interval over the network

    That's literally it
  • 0
    @LotsOfCaffeine was he building in for a likelihood of more sensors and reading types being included or device types that might inclement different ways of gathering the data again ?

    Why do we do this
    Be alive bot !
  • 0
    @YouAllSuck the list of sensors that we monitor was pretty much fixed

    Even then I would prefer to keep a component like that hardcoded.
    I don't think you need a list of sensors that you read out, it's not supposed to be dynamic in my eyes.
  • 0
    @LotsOfCaffeine how many fingers am I holding up ?
  • 0
    @molaram lmao 🤣
  • 0
    @dUcKtYpEd when I asked why they needed an interface for a single class (with dependency injection of course), even though there aren't unit tests that make use of the interface, I got the answer that the "interface is a contract"

    I don't know why we need a contract, but at that point I just stopped arguing
  • 0
    @dUcKtYpEd We use dependency injection for unit tests, by mocking a certain interface and passing that to the application, instead of the real implementation which talks to specific hardware components (which might not exist on during unit tests).

    There it absolutely makes sense
    But if you don't even write that, or hell you make a dead simple component that doesn't do anything special into an interface, you're not gaining anything besides more code to maintain....
Add Comment