this post was submitted on 25 Oct 2025
64 points (100.0% liked)
Programming
23314 readers
230 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Agreed with pretty much everything here. My notes:
I wouldn't recommend the Gang of Four book. Many of the design patterns they espouse are way over complicated from the days of peak OOP. You know, FactoryFactoryVisitor stuff. Usually best avoided.
Agreed. And a lot of it is working around limitations of whatever version of Java was common at the time.
"Visitor pattern" is better implemented as an implementation of Iterator or whatever your language calls that. Everyone knows what "for x in thing" means, but wtf does it mean to "visit" something?
I'd say most of the GoF patterns evolved in a C++ toolchain (and then the Java junior devs started a cargo cult around them that has survived to this day). The book was never as language-independent as the authors envisioned it to be—in fact I'd argue that with the right programming language design the patterns happen implicitly or are obsolete.
I agree with a lot you said and this reads like advice straight from Robert Martins "Clean Code", but I've recently read a discussion between him and John Ousterhout, where John makes compelling arguments for longer, "deeper" functions. I found the discussion very interesting and actually started reading "A Philosophy of Software Design" shortly after. Would recommend!
The section in question: Method Length
I think Ousterhout's observation that deep interfaces are more useful is a very astute one. There is a kind of programmer who finds it satisfying to write lots of boilerplate but it doesn't make the code maintainable.
Short functions can be good because you then name each short section of code, but a comment can offer that more flexibly.
I did feel like Ousterhout kind of undermined his own "comments go a long way in explaining code in longer functions" argument when his example code featured some incorrect comments, which is exactly what Martin warned about.
Honestly neither of them were really wrong anywhere, they just have a different approach. Sometimes I find Martins code split into too many functions, but halfway through there's an example where Martins code is imo definitely clearer than Ousterhouts.
Both of their experience is valuable and is best shared, but not taken as gospel I think.
Thank you for your comment. What are the books you mention in point 1?
I believe this is the "Gang of Four" book:
"Design Patterns: Elements of Reusable Object-Oriented Software"
ISBN: 0201633612
https://www.betterworldbooks.com/product/detail/design-patterns-elements-of-reusable-object-oriented-software-9780201633610