I semi-agree with your comment about design patterns. Some are just silly, like the Factory pattern, and truly are about working around an issue in the language (for example, the lack of classes as first class object in C++, where you could pass a reference to the Class object instead of a function pointer to the factory). Still, it helps establish a bit of language (saying “a subroutine” instead of “you know, put some code here that we can jump to from a bunch of places, putting the return address over here”), and I’d disagree with Mark in that it eventually leads to the languages supporting the concepts, because it gels into peoples mind as the very same thing, as opposed to people getting stuck to the tiny little difference that don’t matter (one guy puts the return address in a register, the other in a global variable, etc). It helps see the big picture.
After a while of “functors” being used in C++, I’m hoping that people will see that they’d really like simple anonymous closures (I’m thinking Perl-style closures, for example), as a first-class construct you can just whip up in the parameters of a function call, say. And it might be possible eventually because we can tell people “what if we made functors even easier and nicer to use?” and they’ll know that functors are, see all those they use, and the prospect of getting a better one could catch on.
Other patterns are really more abstract, like the Facade. I mean, “making a function that calls a bunch of functions for you” is kind of a weird feature one would want to have in a language, and one could argue that, well, we already have it!
But I’ll have to agree that patterns been really abused. What I particularly despise is some people who seem to insist there can only be one particular way to implement a pattern, when someone looks at my code and asks why I didn’t use the Foo pattern, and well, uh, I did, but I just did it different than you. That’s why there’s no concrete “Foo function”, it’s a pattern!
As for the main article, here’s a true life example: a co-worker once made a “Convert” class, that didn’t have any non-static member, just a few conversion methods. To top it off, he instantiated with “new” rather than just on the stack (this is in C++) and bloody LEAKED IT. Wow.
There’s also the opposite trend: the coders who just won’t use the language they’re using. The most common is the C coders who keep using char* and such in C++, complete with fixed sized buffers, overflows and other fun bits (or when using higher-level languages, can’t wrap their heads around a closure). That said, they tend to have to type a lot more to do as much damage as the overzealous OO programmer, so I tend to prefer the C coder (and I can fix their code with small local patches instead of ripping apart some grandiose framework).
