A relative of the Abstract Factory this pattern is remarkable in that it's use is guaranteed to turn any system onto which it is deployed into a brick. There is currently an ongoing lawsuit regarding the IP rights to this pattern (see Microsoft Vs Sony/Starforce)

... coat?

Great article - really struck a chord.

Design patterns are the only interesting improvement in programming since object oriented languages came into widespread use around 1990. Might as well make fun of objects or structured programming.

Better to make fun of programming language boffins for sleeping so long. C++ is old enough to vote for crissakes. Even Java is a teenager. Have we truly invented all things? Can we close down computer science programs and make programming a vocational school curriculum?

Or at least, the attitude that design patterns are the solution is. Design patterns are the symptom of the problem, the solution is better OO languages.

http://blog.plover.com/prog/design-patterns.html

Fun article but all your pattern examples to go 404, as in, The requested URL /wiki/Factory_method_pattern was not found on this server.

Or perhaps it's just the hidden pattern incorporated within your article.

Actually, Fragile development is probably not a bad term for it. As Wikipedia points out, Agile programming is probably similar to the environment that we were working in 30 years ago.

Unfortunately, the individuals doing the programming in the agile environments don't seem to have the necessary knowledge and humility to gather and learn requirements. We were probably as arrogant back then, being young, but we also had a depth of business and organisational discipline knowledge missing from todays developer.

Consequently the agile environment is not delivering the benefits it did/should.

Its a shame because the tools are so much better.

There are many already using these patterns, they must be very powerful, especially the lethargic initialization pattern. Nothing wrong with making fun of this delusional crap, it's only funny because it's true, and it is funny.

Anti-patterns are often more useful than patterns and these are some great anti-patterns. I recognise a lot of them from the code I'm maintaining. What about the Factory pattern that only creates one type of thing? Template classes that can only have a single type in the instantiation? Those are good anti-patterns for obfuscating your code too. I've also got some smart pointers here that aren't very smart (like a reference counted pointer that actually takes ownership like a scoped pointer). They're great for really hacking off the maintenance programmer.

Like the Abstract Bridge pattern, Vague Bridge provides us with a loose and therefore replacable coupling of two implementation classes. The Vague Bridge pattern, however, gives us the additional guarantee that couplings and abstract references may be null-ed at any moment, resulting in joyfully non-deterministic behavior and in new bugs in software that was already tested and declared final.

Why was I not surprised that you work with Java? Been developing in Java for 12 years, seen it all. Ick.

It's not Design Patterns that are holding people back, it is the inability to differentiate between the occasions when known design patterns are appropriate solutions to a design problem and when it's time to do some design of your own.

In the end, it's never really the language or the tool or the book you are using that hold you back, it's the belief that you only need to use one language, tool or book.

a suggestion from one of my colleagues here: 'The Olfactory Method'... code that smells.

Refactory... the fashion of the moment: How about the old maxim of 'If it ain't broke; don't fix it', or at least the wisdom of if cost of change > benefit of change => don't change...

And the Mallory pattern... implementation of a design pattern 'because it's there'. Often leads to the Delicate pattern via the Fragile method.

wiz

Oh, good show on this article! Ignore the naysaying ninnies, they haven't paid attention to squat!

Software design is old. "Patterns" are just some fancy names for stuff we've been doing all along. What always amazes me is that software design and engineering JUST ISN'T BEING TAUGHT!! The design books from COBOL are still relevant! Object-oriented languages sprouted in the 1960s, with Simula. And you guys make a pretense that you have something that is wonderful and good? Heck, no! Multics, from 1965, had more security than our current OSes!

Just because somebody did something today doesn't mean that they did something better than yesterday. For some reason what was learned DECADES ago isn't being taught today. WTF is wrong with the educators? They are supposed to prepare students to be effective programmers, not screw around on their little fief and produce morons. Students coming out of colleges can't even type, use an OS (Windows or Linux), or even hook up a computer to a KVM. Colleges are nothing but a debt machine.

What you knuckleheads don't understand IS THAT YOU AREN'T BEING PAID TO BE SCIENTISTS! You are being paid to get an application out the door. Got the concept?? Vocation and business go hand-in-hand. If the state of computer languages upsets you, go and design one yourself! And remember, it needs to get things done in the real world!

What a load of rot. Your article contradicts itself; you describe how all machine language programmers adopted a standard way of doing subroutine calls (a "pattern") which was good and so eventually got incorporated, yet you imply that patterns are in some way holding us back.

Patterns are part of the evolutionary nature of languages and frameworks. It's survival of the fittest at work, ensuring that bad practices fall by the wayside to better techniques. Given time, the very best may well be incorporated into the language.

Whenever I see pattern bashing, I suspect some form of dishonesty.

Consider this. You encounter a problem, which you work on and do not solve very well. You encounter it again, and improve your method of solving this problem. You encounter it yet again (sorry to be repetitive, but it makes my point), you use your improved method of solving the problem, and it works great! If you continue to encounter this same problem in the future... will you use your trusted, tested method to solve it, or will you forget all you've learned in the past and attack it each time as if you'd never seen it before?

If you are sensible enough to decide that your trusty way of solving that problem is probably the best approach to use in the future (at least until you find a better way), then you are dishonest if you say that you think patterns are worthless. If your only argument is that some people get too carried away and try to bang square patterns into round problems (or that your one trusty solution will not solve all types of problems), then please just say so. Everyone who believes patterns to be valuable will agree with you, and there will be no argument.

Interior Decorator - doesn't change functionality, but improves Feng Shui

Voyeur - like Observer, but observes objects that are not otherwise Observable. Related to Stalker, which acquires references to instances of other classes without their consent and calls their methods at random.