In a galaxy far far away, there was a kingdom where people didn't know structured programming. Their programming languages only had (conditial) branches, jumps, or GOTOs (as they were colloquially called). And they had a very influential programming book, called "GOTO design patterns". Here's a few examples of design patterns from the book:<p>- "IF pattern" - If you need to execute code only if some condition is true, you write a conditional GOTO that lands after the code that is to be executed conditionally.<p>- "IF-ELSE pattern" - If you need to execute code only if some condition is true, and some other code if the condition is false, you use IF-ELSE pattern. It's similar to IF pattern, but at the end of the code in the IF pattern, you add another unconditional GOTO that branches after the code that is to be executed if the condition is false.<p>- "WHILE pattern" - If you need to repeatedly execute code and check some condition after each execution, you add a conditional GOTO at the end of the code that goes <i>back</i> to the beginning of the code you want to repeatedly execute.<p>- "BREAK pattern" - This is a pattern to use with the WHILE or UNTIL patterns. If you need to, on some condition, stop repeated execution of the code in the middle of the code, you add a conditional GOTO into the middle of the code that just branches <i>after</i> the repeatedly executed code block.<p>Everyone was happy with the book. No more messy spaghetti code full of random GOTOs (as was common before the book appeared), because young apprentices memorized all the patterns in the book, and they just applied them rigorously. Also, understanding code became easier, because everybody instantly recognized those patterns in the well written code, and they had a common vocabulary to talk about these things.<p>One day, a traveler from another world came into this kingdom. He looked at the book and wondered: "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" Unfortunately, he was executed for the heresy.
I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived.<p>Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with <i>most</i> science/technology analogies, to be honest.
The main value of the design patterns is that they have given names to things that were already common and fairly intuitive to a half decent programmer.<p>But I've come across many people trying to use them as a guide for how to write code - and misunderstanding them. Factory in particular is often misunderstood. It is mainly useful when you have parallel class hierarchies not as some odd wrapper around all the constructors in the software.
The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.
I think the reason that some of these patterns seem so terrible in real code is limited static type systems / OO - I'm specifically looking at Java, and it's terrible type erasure, and poor (but getting better) functional programming support.
One can argue these topics until the cows come home, and possibly later. One can strongly argue for/against imperative programming, functional programming, OOP, design patterns, Design Patterns with Cool Names, Design Patterns as Implemented in Your Favorite Language, etc... At the end of the day, the only thing that matters is whether your team thinks your source code is structured or not. If you're on a team of one, well then you have your future self to contend with.
In my opinion, iluwatar's design pattern guide [1] provides more examples than this. It gives not only implementation examples but also a class diagram and use case for each design pattern. The examples were implemented in Java.<p>[1]: <a href="https://github.com/iluwatar/java-design-patterns" rel="nofollow">https://github.com/iluwatar/java-design-patterns</a>
I wish there was a resource that goes over design patterns with more abstract concepts/classes. I found the example in GoF to be somewhat useful but at a certain point (near the middle) I got lost in the details.
Stop the for humans meme. Try-hards use it to signal that they're "in" but its outlived any meaning beyond some meta-meaning which is no meaning at all. Just make your project quality. Don't proclaim it, just do it.
Object-oriented programming is a disease, and I can't wait until we're collectively done with it.<p>All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language.<p>The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and carry around in their heads, is a crime against our profession.