Do you call everyday life commonalities for “xxx pattern”, like you obviously do for a programming “design pattern?” Like, say, the “opening pattern” which can be applied to car doors, cans, and caps. I doubt you do. In fact, I doubt you label any commonalities outside of programming a pattern (in the “design pattern”-usage sense) even though you clearly could. Ask yourself why is what? No, really. Apply the opening pattern to your mind and consider deeply why we don’t see people talk about “design patterns” in carpentry (the “v-claw pattern”) or mathematics (the “substitution pattern”) or any other field and then draw the obvious conclusion.

And of course I’m overstating! The message would be muddled if I said that something is 98% bad. The message remains the same though: pattern terminology and usage thereof rots the brain.

BTW, data structures have nothing to do with design patterns, and vice versa. Why mix them? Data structures (like algorithms) are language independent, design patterns are language dependent. The former (two) is timeless knowledge. The latter is perishable knowledge (with a best-before date of 1994)!

That said, it sure is refreshing to find somebody stand up and publicly say denounce something that seems to have been so widely accepted without much apparent scrutiny. Even if I think you’re overstating the issue, I agree that more scrutiny is warranted before you go trying to memorize the design patterns book.

I actually teach a course that covers both Data Structures and Design Patterns. For my part, I try to focus on how these are both about recognizing the repeated patterns that come up in programming. We’ve all developed our own patterns over the years, and the wiser of us have managed to learn some tricks from each other. I try to stress for the students that these patterns are useful as options to consider, and only by understanding exactly how it works would you be able to apply them wisely. However, I see the blank stares in some of the faces, and I know they would rather just memorize “Plank” problems.

I’ll give your ideas more thought before I prepare my lecture notes the next time around.

Keep up the scrutiny!

> I see you’re missing the point.
I don’t know. I might have missed the point you were trying to make, but I don’t think I’ve missed the point of design patterns.

> In carpentry, there is no group of “carpentry masters” who holds classes telling carpenters to use the
> ‘new’ “glue pattern” while poo-pooing the old way of gluing.
Oh I couldn’t agree with that more! Consultants trying to sell coursed on design patterns, scrum coaches, or certification businesses… pretty much all of them are money making machines with no particular benefit for the buyer, IMO.

I just think it’s well worth looking past that towards what these things they’re peddling actually /do/. As far as I am concerned, learning design patterns does not a better programmer make. But knowing the names of design patterns might make it easier to communicate large, abstract ideas from one programmer to the other. I see benefit in that.

Similarly, I’ve had excellent experiences - as well as terrible experiences - with applying scrum. No amount of scrum coaches I’ve talked to have /improved/ my experiences; on the other hand, the process itself can be applied successfully.

I don’t have a similarly good view of certifications. Sorry, they’re really the spawn of the devil ;)

Hope that makes my point a bit clearer.

I’ve wondered about this thread based on my own experience and I can’t help but agree with Christer.

My first instinct was to wonder how labeling algorithms or data structures is any different than labeling patterns, but algorithms and data structures are much, much more concrete and applying them has very measurable results.

And while this may seem harsh and overly judgmental, in my experience, the best programmers/engineers are the ones that think in terms of data and algorithms. Those are also often the best architects, because they truly understsand what encapsulation means or they otherwise would not be able to seperate data and algorithms (and I don’t consider encapsulation to be an OOP-only concept, I say this because Christer is obviously not an OOP fan!).

By contrast, programmers that litter the code with pattern usage are usually the ones that cause the most trouble. They absolutely have to label whatever code they create with the pattern they picked from the book. Those are the programmers that love to explain how an Adapter is different than a Facade or a Decorator, etc, and who include the pattern names in whatever new classes they’ve created instead of just trying to name a class with something that captures its purpose. They also think that labeling something with a pattern makes it clean, and that it’s okay for WhateverAIObjectFactory to be known by the entire codebase because it’s recognized pattern. They go through great effort to systematically incorporate pattern names in their language and are completely unaware of the “real” problems other engineers are solving daily to make the game fast and ready for ship. To me, those guys are trouble.

Patterns exist, and whether they need to be labeled or not can be debated. All I can say is, when I see very explicit pattern usage, my alarms trigger and I pay special attention! And that’s a reflex that has been burnt in me over time.

–

Oh, just a minor note. One thing to that keeps coming up whenever subjects such as over-engineering, pattern bashing, etc, are in question, is the architecture vs performance/hardcore programmer comparision. I don’t know why, but there is this assumption that you either architect code well or make it fast, and that if it’s fast it must be unmaintainable (one of the earlier comments touched on that). I don’t know why that is. I am in favor of both architecture (not OOP style though, way more in the way of DOD) and obviously speed, but I consider them orthogonal problems. It is actually easier to optimize parts of the code when that code is well isolated, sticks to solving one thing, etc.

Cheers all.

In carpentry, there is no group of “carpentry masters” who holds classes telling carpenters to use the ‘new’ “glue pattern” while poo-pooing the old way of gluing. There is no group who tries to tell other carpenters what to do or what to call it. Carpentry nomenclature occurs naturally, on the job, not from some club of theory-only carpenters selling expensive coursework and books.

Indeed, it appears all other disciplines are quite sane, and it is only in software development where we have enough feeble-minded people that we have been taken in by a bunch of snake-oil salesmen selling made-up, out-of-the-blue, nonsense terminology like, say, “flyweight pattern.”

I repeat:

The presence of the “pattern” term (the “‘pattern’ pattern” if you will) is the indicator of what’s the problem here. Standard terminology appears naturally, as witnessed by terms like “divide and conquer”, “dynamic programming”, “callback”, etc.

What the Book from Hell did was to force standard terminology down everyone’s throat, instead of letting natural selection have its course. This has resulted in a bunch of mindless sheep now thinking that there is some sort of inherent value to “visitor patterns”, and worse, that anything categorized as a “pattern” is good.

It goes without saying that terminology is important, but relevant and precise terminology arises natually, from a need! “Callback”, for example, never had this cult or passionate discourse about its being, because that term arouse naturally. But there was never a natural need for labeling of encapculated global variables as “singletons” or other similarly trivial concepts as “visitor”, “observer”, or what-have-you patterns. These patterns are entirely artificial concepts, borne out of the only need they were ever close to — the need for academic masturbation!

People thinking any forced pattern-name is important have been bamboozled. They have been fooled, just like people believing in the value of homeopathy, astrology, phrenology, or navel-gazing have been fooled.

Just like I’m sad to see people get harmed by using homeopathic “medicine” I’m greatly saddened to see software developers harming software and their profession by applying “pattern-names” and, worse, “pattern-thinking.”

It’s true that there’s only one way to drive a nail into a piece of wood. On the other hand, there are plenty of ways of joining two pieces of wood (go ask carpenters about that, if you must bring them into the discussion). The “hammer-nail” pattern is just one of them; offhand I’ve personally used the “glue pattern”, the “wood plug” pattern, a combination of the glue and wood plug pattern, the “screw pattern” and even some attempts at proper joinery. err the joinery pattern.

You don’t need to call it a pattern if you hate the word, call it a technique.

Carpenters are lucky compared to us in that even the most complex technique of joining two pieces of wood they employ can be described — not exhaustively, but to the point that they can be identified — in a few informal words. And yet even they resort to formal terms where needed. I recommend starting your reading here: http://en.wikipedia.org/wiki/Woodworking_joints

Perhaps you see more bad programmers as a director than I do as a lead (which would be kudos to my TD for weeding them out before I have to), but to me, the problem isn’t “design patterns”…it’s “Javaschools” (I’m sure you’ve seen it but for those that haven’t, I strongly recommend “The Perils Of Javaschools”

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

and the link within (which, not coincidentally, buttresses another of your themes), Paul Graham’s “Beating The Averages”

http://www.paulgraham.com/avg.html

Ok, just so long as you aren’t calling the vast majority of perfectly competent, productive, and non-pattern-zombie professional programmers “fools” simply because they have never had cause or need to do photon mapping…because that wasn’t really clear from your earlier clarification.

unwesen, on the silliness that is your “[design patterns are] no more than a name for an approach to pounding nails into a board” analogy. Ask yourself, do carpenters have different names for “approaches to pounding nails into a board”? (Go ask a carpenter. No, really, go do it!) Of course not! Unlike programmers, carpenters are intelligent people, and they wouldn’t even dream of doing something as moronic as assigning a name to nail pounding!

Kenneth, these are all perfect examples of academic questions that have little practical value beyond getting someone a thesis. These questions and attempts at answering them do not belong on my blog. This blog is for discussing real-world issues.

Greg, “language dependent” is not a singular but a plural reference to languages. And, yes, I’m 100% serious, modulo the five somewhat randomly picked subjects of the sentence.

“I mean, if someone thinks they are a better programmer for knowing the “visitor” and “observer” patterns, but they don’t know, say, what a skiplist is, how to perform a k-nearest neighbor search, or how to apply dynamic programming to a problem then they’re fools.”

Because you clearly aren’t serious here, and are just trying to make a point?