Misused design patterns

Question

Are there, in the canonical Gang of Four list, any design patterns that you often find misused, misunderstood or overused (other than the highly debated Singleton)? In other wor

Answer 1

ALL.

Don't take me wrong here, I find them to be a great base and when understood well very helpful. It takes so much out of you to acquire the design skills to know well when and how to apply them in the code. Actually, that's the overall case for the skills to create clean code.

Its not about not using then, is exactly what you said in the question "think twice before using". Understand well what you are doing and why. If you don't, talk to someone that can coach you on that - besides reading a lot. Beware of the ones that know all the patterns but can't explain you clearly the what/why of any of them - specially of the one in question.

Answer 2

I just wanted to add another comment after seeing some of the "All patterns are bad" answers.

If you are a half decent programmer working on moderately challenging problems, nearly all the patters should have presented themselves to you at one point or another as the "Obvious" solution to a problem.

The only real point of the Design Patterns book was to put names to what we all do every day so we could communicate better.

I suppose if you are a newish programmer, it would be very helpful to read through them so that the day you need one you don't have to figure it out on your own, it's already in your toolbox, but in general--any of these could be figured out by a Gang of One (anyOne!).

If there are any of these you didn't already know, you probably just never needed it.

It is pretty useful to put names to the patters and formalize them a little though, I'm not complaining about the book at all. If you don't see the occasional need for nearly all of the patterns here, you just aren't working on very hard code (or you duplicate code a lot, something I consider THE cardinal sin).

Answer 3

The Mediator pattern definitely has the potential to be misused if all sorts of logic gets globbed into one huge class.

Answer 4

Only use a pattern when its called for. You can't predict the future, so while you might put a pattern in to make the design flexible, what happens when the product takes a different direction and your pattern becomes the very thing that's keeping you from implementing what your users want?

Keep designs as simple as possible to start with. When you know more about how your design needs to change, use the appropriate pattern and not before.

Answer 5

Actually, I would say design patterns in general are overused when a KISS (Keep It Simple, Stupid Keep it Short and Simple) solution is all that's needed.

Design patterns are great for making a system flexible, but at the cost of making the implementation more complex. This is only a worthwhile trade off when the flexibility will provide a practical advantage.

Answer 6

First, "it depends" on the language - some structures in some languages lessen the need for certain design patterns.

Second, part of the template for the concept of a Design Pattern from the start has included sections for "Applicability" and "Consequences" - ignore these at your own risk. "Knowing" a pattern doesn't just mean you know how to code it in the language of your choice - it also means knowing when to use it, and what drawbacks using it may entail.