I've been hearing and reading about cases when people had come across cases of overused design patterns. Ok, missused design patterns are understandable phenomenon. What does it actually mean overused design patterns?
Do you have any examples and why do you think there are too many patterns?
This was actually discussed by our one and only Jeff Atwood on Coding Horror:
I would say the Singleton is well overused. There are often much better solutions than using what's essentially a global variable.
I guess Singleton gets easily overused (though it certainly has its legitime uses).
Addiction to the Singleton pattern is called Singletonitis. :) Symptoms include, at least, unnecessarily high coupling, and testing becoming more difficult.
Edit: As a prescribed cure for Singletonitis, you could try Inline Singleton, described in Refactoring to Patterns by Joshua Kerievsky.
Edit 2: For a good discussion on Singletons, see this older question: What is so bad about Singletons
The singleton pattern, which is only suitable in a very few cases and makes testing harder. It's not only over-used, but it's often badly implemented in Java and C# - people often rush into double-checked locking when it's not only inappropriate but also relatively hard to get right.
EDIT: I really should have realised that everyone would post the same thing.
Next example, the factory pattern and in particular its use in the Java DOM API. Blech.
The singleton is probably the most overused design pattern. I often see it used in many cases when it's out of scope and much more appropriate to directly instantiate objects.
After that, I believe the factory pattern is way overused as a shortcut of instantiating objects, many times without a real need.
I'm going to weigh in on the much-overused Singleton. Quite often, developers learn only this one pattern and use it when a static class would be just as effective.
I too vote for Singleton: a global in abstracted clothing.
And Factory, since that makes it easier not to think about how objects are connected together in a given program.
MSN
I vote for ActiveRecord.
Many popular data access frameworks use ActiveRecord as the only data access pattern, a sort of one-size-fits-all solution, even though Martin Fowler's book "Patterns of Enterprise Application Architecture" describes several other data access patterns, and details strengths of each pattern and how to decide when to use each pattern.
PREAMBLE: Generally, Singleton is considered the most abused pattern, if for nothing more than the fact that many will use it to write in-line programming in fact, if not in actuality, while others use it as a substitute for global variables.
BODY:There is a book out there called, "A Pattern Language" which predates the illustrious GoF by several years. It calls for a similar language among different aspects of a project — it was apparently a major influence on "Design Patterns" and those who know both texts consider it superior.
My personal experience is that the GoF is only useful in certain circumstances, and a far cry from encompassing all of OOP. I actually find it quite amusing that several of the patterns are made obsolete in other languages, and others are merely redundantly describing the same scenario (Is there really that much difference between something which adapts and translates?)
Patterns, in general, are a good thing. It is good that Singletons generally use a static getInstance method. It is good that many MVC structures use similar naming conventions. On the other hand, Patterns are not everything and that needs to be remembered.
Recommended reading: http://perl.plover.com/yak/design/
The (sometimes) so-called JavaBeans-Pattern: getters and setters for every field. Highly questionable and extremely widespread.
Object Orientation, which is no longer a design pattern but a way of life. I have seen a lot of procedural code munged up in objects and a lot of objects for the sake of objects because the zeitgeist says "presumably you are object oriented", when a few lines of C and a struct would do just as well.
I cite it as the most over-ued design pattern because it is (probably) the most widely used design pattern and its merits are rarely questioned.
I think a worse problem than overused design patterns is patterns misapplied by enthusiastic developers who've recently learned a new pattern tool and decide they need to try it out. Recently I've been reading some of Misko Hevery's blog (http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/) entries on dependency injection. One of his major assertions is that the singleton pattern implemented as a global instance severely limits testability and should be avoided.
A few days ago I read an interesting opinion on patterns from Christian Gruber's blog. He suggests they are useful as a tool for discussing architectures, but shouldn't be used during design conception lest software architecture deteriorate into what he calls "paint by numbers." See the paragraph on Design Patterns: http://www.geekinasuit.com/2008/12/testability-re-discovering-what-we.html.
So possibly the issue with design patterns is misapplication and tunnel vision induced by the perception that all well designed software must fit into one of the patterns described in Gang of Four.
I keep seeing the Provider pattern used where there is only one provider. This seems like an awful lot of extra work with no benefit.