In most design discussions, anybody who knows some design patterns immediately peep up and relate the pattern they know to current problem. And suggest using them, even if your requirement is so simple. They say using design patterns will make your design extensible for future. Is this a healthy sign? Not really!
Maybe good when considering the developers in the team had learnt about the design patterns, which help them to make good design or even to implement a good design correctly. But putting the patterns up-front in the design phase often causes over engineering.
Avoid using patterns unless you really need them. KISS. Keeping things simple will help even a newbie to understand your code. If a person is not comfortable with your code, he will start modifying the code in isolation (i.e. modify only the parts he is comfortable to change, and add utility classes / separate functions to do his job, rather understanding the whole piece and adding the code at right place).
Throwing in design patterns early is a costly solution to a non-existent problem. By doing so you waste your resources to implement the pattern with complex code, than concentrating on you business requirement. As an XP practice, always remember don’t do more than what it requires. Don’t spend time in solving anticipated problems of future rather keep the code clean, so it can be implemented if required in future.
Are patterns to be avoided then? No. They have to be used with care and consideration. Similarly patterns examples shown in the books are just reference implementations, we should be comfortable to modify it as we need to keep the design simple at the same time keeping the grammar of the pattern unchanged (to avoid confusion in pattern vocabulary).
Some designers count the number of design patterns used to show the quality of their design! That’s the worst way to measure the quality of design. So beware, over-engineering is an equally dangerous as under-engineering.
Under-engineering is another problem with software development. This happens usually when the developer has no intent to organize his code, or to improve design. All he writes is code, which claims to work right, but still can’t be proven. Working with this code is a nightmare. Enhancement or even maintenance is almost impossible.
No special knowledge or attention is needed to write this kind of code. It happens automatically as your program evolves. Under-engineering is most commonly seen in practice. This type of code finally becomes a Big Ball of Mud as described by Brain Foote.
Starting with simple design, and re-factoring continuously to improve design & readability of the code helps to achieve a best possible design for a given requirement.
Refactoring to Patterns is a good book to start learning about this paradigm. This book is specially published under signature series signed by Kent Beck, and Martin Fowler
Home Page of the Book: http://www.industriallogic.com/xp/refactoring/
Martin Fowlers link: http://www.martinfowler.com/books.html#r2p
