Andreas Schaefer writes an interesting blog about design patterns. I don't agree completely. Everyone uses patterns. But getting excited about it is a little like getting excited about the fact that I breathe through my nose. Anyway, it's good to read some free thinking on this subject. It's one of those things where a whole cadre of people will thwack you over the head for not "getting it" if you point out that the emporer is, at best, wearing a g-string. I get it. There's just not much it to get.
I've heard decidedly kooky things about patterns (usually from people who don't code for a living). Typically it's the same type of hype that says that one day, in the land of milk and honey, all software will be made by "component assemblers" (who presumably get paid minimum wage). I'd like to coin a term for these thingies - YAWMTI - Yet Another Way to Make Talent Irrelevant. Yawn. Hasn't happened yet. (Hmm, YAWMTI doesn't really roll off the tongue does it? Maybe I should stick to my day job...).
When the gang of four book first came out, someone in a job interview suggested I buy a copy and read it. I did. It was disappointing. I just felt like, isn't this kid stuff?
There's nothing wrong with formalizing the obvious and the mundane. But it's really worth remembering that that's all design patterns do. There are no panaceas or silver bullets lurking within design patterns. It's a "pattern language" - a way of talking about doing, not a way of doing.
It's true that people create abstractions, and then build new abstractions out of those abstractions. Programmers are often (perhaps too often?) in the abstraction business. Coming up with a formal name for one or another abstraction is fine - it can indeed end up being a useful communication tool. But sometimes people forget that that's all a pattern is. Code is real, abstractions aren't - a pattern is a very lossy-compressed version of things you code every day. You can sleep in a house. You can't sleep in a blueprint for a house (well, maybe if you're very, very small...).
I expect there is quite a bit of value to patterns as a teaching tool - they could be a great way to teach people new to programming ways of thinking about what code does. Such mental tools are otherwise acquired through experience, reading code and ad-hoc "Aha!" moments, if at all.
Where the real value of design patterns ought to be is as a way to describe, to a machine, code that it should generate; and more interestingly for reverse engineering - identifying patterns in existing code, and using that information to visualize or describe what the code does to someone unfamiliar with it. Now that would be a useful application.
But trying to shoehorn all of my thinking into a canned set of predefined patterns? That's just silly.