Originally posted by Hendy Setyo Mulyo: There are so many patterns in a project, design patterns and now is implementation patterns. What is it for? Is it for replacing design pattern in a framework construction or to support it?
Implementation patterns aren't supposed to replace anything. They're simply documented, common ways of structuring code and thus don't overlap with design patterns at all.
In your question I hear frustration at the proliferation of patterns. There was already a huge pile and now here are more.
From my perspective, these patterns don't represent new knowledge. The techniques described are all quite ordinary. In fact, some readers are frustrated that there aren't more wizard tricks in the book. The contribution of the book is selection and explanation. In writing the book I selected those techniques most likely to be understood by readers and I explained how and when to use those techniques to maximize communication.
You might want to read the sample chapter on InformIT and see if my selection and explanation process is helpful.
Kent Beck Three Rivers Institute
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007434/ref=jranch-20" target="_blank" rel="nofollow">JUnit Pocket Guide</a>
Dear Hendy, When listening to a recent podcast from Software Enigneering Radio (se-radio.net), Bob Hanmer put patterns into context like this: These are for having heard of them and putting them into your toolbelt until the situation arises that you need them. Then refresh your memory and use them if appropriate.
Implementation patterns are a bit differenent as you use them much more often than design, architectural and all the other patterns. To go with Cristopher Alexander - implementation patterns are the stuff that makes the code alive (i.e. communicating, simple, flexible) and that capute the quality that can hardly be named otherwise. It is very difficult to describe the things that make code great - patterns are a very useable way of doing this.