maybe a bit off topic, but I think it covers your question too: I would suggest you a good book Refactoring to Patterns:
This book introduces the theory and
practice of pattern-directed
refactorings: sequences of low-level
refactorings that allow designers to
safely move designs to, towards, or
away from pattern implementations.
Using code from real-world projects,
Kerievsky documents the thinking and
steps underlying over two dozen
pattern-based design transformations.
Along the way he offers insights into
pattern differences and how to
implement patterns in the simplest
possible ways.
you will find examples when design patterns are good to use, as well as when you need to go away form them, not to make application overcomplicated. And yes, the main idea is to keep everything as simple as possible.
Good answer/advice to your question was in article Do You Recognise the 4 Early Warning Signs of Design Pattern Abuse?, but I can't load it now, error 500. It is not big, so I just used google cache to get it:
Software design patterns can and do lead to over-engineering
Over-engineering is the process of
over complicating something. In the
case of programming, making your code
more complex and possibly more
flexible than it needs to be. More
specifically, implementing complex
software design patterns on simple
problems.
1. Start simple not complex
How does this happen? Usually you
program in extra functionality that
you anticipate will be used or prove
to be useful later. But what happens
if this need never materialises? In
most cases, the cruft gets left there.
It doesn’t get removed. So the
software system continues to grow in
size and complexity with all these
features that aren’t ever being used.
2. Be wary of the signs
This is perhaps different for everyone
but I suspect in most cases, it isn’t
really a conscious effort. But rather,
it is something brought about by the
fear of being stuck with an awkward,
inelegant, inappropriate or simply
put, bad design; being stuck with
something that just isn’t flexible
enough. Ironically, if you get to the
point of over engineering or over
applying patterns you are right back
where you started.
Software design patterns appeal to
programmers or developers because they
allow them to naturally express and
create beautiful architectures. It's a
part of enjoying creative programming.
3. Consider refactoring to a pattern rather than starting from one
What might be a good way to avoid this
design pattern abuse? Consider
refactoring to a pattern rather than
starting from one. Don’t start out
trying to force a pattern into your
design. Chances are your design could
be much simpler without it. If you do
find at a later stage that your design
truly could benefit from a structured
pattern, then refactor to allow for
it. When you design, solve the problem
in the simplest way possible. Simple
light weight software is always a good
thing. There are better ways of
avoiding the under-engineered
alternative where you get stuck with a
design or solution that just isn’t
flexible enough or doesn’t suit the
problem.
4. Don’t force yourself to get it right the first time
Forcing software design patterns or
structures into design just isn't the
answer, that's just bad design. But
prototyping or building an initial
build0 (proof of concept build before
production on the actual product
begins) can help avoid this and the
problem of over-engineering. Because
you don't feel like you have to get it
perfectly right the first time.
Original URL (now dead): http://codelines.net.au/article/do-you-recognise-the-4-early-warning-signs-of-design-pattern-abuse/