332
OOP at home:
(feddit.nu)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Feb 2026
332 points (100.0% liked)
Programmer Humor
30038 readers
1108 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Its the best/worst thing about OOP no matter what language.
We had a rule at work that if you are 3 levels or more down an inheritance tree, then you are too far. The cognitive load is just too much, plus everything stops making sense.
One level can be great (MVC all have great conventions, MCP as well). Two can be pushing it (Strategy pattern when you have physical devices and cant be connected all the time, Certain kinds of business logic that repeat hundreds of times, etc...) But even there you are kinda pushing it.
I need code that I can look at a month from now and know WTF is happening. And sometimes its better to have less DRY and more comprehension. Or maybe im just a forever mediocre dev and dont see the "light". I dunno.
This is exactly how I feel too. A little bit of repetition is totally worth it, versus having inappropriate coupling, or code that jumps in and out of parent/child classes everywhere so you can hardly keep it in your head what's going on.
I freely accept that I AM a mediocre dev, but if that lends me to prefer code that is comprehensible and maintainable then I think being mediocre is doing my team a favour, honestly.
@tiramichu
It's this mentality that shows you aren't mediocre. Simplicity requires more skill, not less.
@mesamunefire
Thats kind of you to say 😀
Yup. They made it to the other side of the bell curve meme. Most developers have an OOP phase until they learn that it's utter bullshit.
@jason
I do like being able to easily bundle properties and functions together. I think objects are useful if kept in their simplest form.
Though I think some would argue that not using inheritance and interfaces and such precludes it from really counting as OOP
I can definitely respect a limited approach. I personally don't find any benefit from it. Anecdotally, I've become much more productive since switching from OOP style C++, to just straight C. I think a lot of that comes from the boilerplate and ceremony required to make it do the thing, but in C, you just do the thing.
I also think even using objects tends to encourage poorer design choices by thinking in terms of individual items (and their lifetimes) which is enforced by the constructor/destructor model. As opposed to thinking in terms of groups of items which leads to simpler and safer code.
PTSD flashbacks to the codebase I started on in 2008 which had... I don't even remember. Like six or seven levels. Fucking nightmare. I did a printout of the analysis Doxygen gave me and it ended up as a 4x3 meters poster ;_;
WTF
When I first started using Go I bemoaned the lack of true inheritance and classes. Now I love it.
I thought it didn't have classes in name only, isn't a struct with methods basically a class?
Depends on what you mean by “basically a class”. If you mean inheritance, overriding, and more generally class/inheritance based polymorphism, no, it does not. Those require dynamic dispatch, which Go does not have (for concrete types, which is what we’re talking about here).
a class can be inherited from, a struct can not.
composition can help with all of that. factories, strategies, injections are all composition patterns that work fine.
business logic that repeats? extract it to it's own thing (class, function, etc) and pass it as a param to the supposed childs.
mvc? controllers don't need to extend anything, just have them accept the framework through the constructor and request and response as args. views? same. models? perhaps only if doing an active record, but a repo pattern with plain objects is a good pattern too.
I never seen a clean inheritance implementation for a decently sized problem. it mostly works for tiny ones.
@mesamunefire
@tiramichu
I totally agree on this. I found that often things that appeared to need inheritance at first glance often didn't if I gave deeper thought to it.
Granted I was working on much smaller projects rather than crazy huge multi team enterprise apps, but I'd guess that even then this is a good "rule of thumb".
Cool, good to know someone else has the same experience.
Ive been on a couple of multi-year projects and they are NOT fun with OOP + developer went crazy with patterns they were experimenting at the time. Its what made the "rule" pop up to begin with.