A Solution Formerly Known as a Design Pattern.

It used to be, back in the day (I hesitate to say "good old days'), men didn't wear low-cut jeans and fancy pouch-ed thongs, they wore purple stretch pants with black leather chaps like the cross-dressing bullfighter they always, deep down, wanted to be. Back then, a Design Pattern solved design problems. Things called tips, suggestions, best-practices, what-have-you took care of the nuts and bolts. Not any more.

Design Pattern. The moniker of our dear old friend has been commandeered. To maintain some degree of sanity and integrity, perhaps a name change is due, but to what?

Times change. Things reach equillibrium. Prince is now Prince again, and all is well with the world… almost. Admittedly, a Design Pattern isn't likely to look nearly as good in sparkles and ruffles, or hang around with the likes of Shiela E., but then again, it isn't likely to give you the clap either.

What else, pray tell, would suggest the power of the Design Pattern? The majesty of the Design Pattern? The purpleness…?

Hey, the way I'm figuring that, since he's done with it, we might as well commandeer his interim moniker for our friend, the Design Pattern, whose identity (like the gender of some musicians who will not be named) is often confused with something rather different.

Everybody's got one these days—a "Design Pattern", not a wackadoo symbol. Heck, some folks even have a few blog entries discussing some new technique they affectionately call a Design Pattern. "What's the matter with that?", you ask. "They solved some problem or another didn't they? Who cares what they call it?"

I do. Why? For all sorts of reasons that are much too involved to discuss but will be left as an exercise for the reader to uncover. One, though, upon which I am determined to hold forth (or at least whine a little).

Perhaps amid the ever present discussions of whose MVC interpretation is bigger, ahem, I mean better, the notion that a pattern, of which MVC is but one (arguably a group of patterns, but nonetheless), is a generalized solution—one that, setting aside architectural differences, may be applied in many very different domains, including those outside computer science like the business end of the music industry.

No, not that business end, but I can tell you know what I mean.

Instead, somebody figures out you can bind two member variables in different classes entirely in ActionScript rather than MXML, does a write-up about it and calls it something like the ActionScript Binding Pattern.

I am (seriously) grateful that folks would take the time to share techniques they've discovered. Heck, that's kind of the point of an online community. But every solution doesn't imply a Design Pattern, and to call a technique a Design Pattern, only further reinforces this misunderstanding. To the point where it almost doesn't matter what Design Patterns were historically, it only matters what they've become.

Just ask one of the millions of VW owners walking around how important the providence of the things they buy are to them. Better yet, ask one of the millions of Jewish VW owners walking around.

Not to say that change isn't good, and perhaps language should bend to the people's will. But when is it the people's will and not just the people's ignorance?

I guess it's just a Sign O' the Times. Let's go crazy.