Probably, we all know definition of design pattern from wiki that its general reusable solution to a commonly occurring problem. And of course we have thousands of web pages over internet, telling about these patterns every now and then. Aha! Don’t forget those dotfactory for GoF.
So the natural question that comes in my mind is, WHY one more? Here is the answer I got from within
While many people know these patterns by definition and by class diagram, what is missing really is what they actually mean when it comes to applying them in practical scenario. Most importantly knowing when to apply and when not to (Nothing is as bad as applying design pattern at wrong place). Besides, what matter more in practical cases are design principles and not just blind application of any pattern (just because you know that pattern). After all ultimate goal behind any design pattern is to encapsulate what is changing.
With that in mind, I am planning to start with series of blog on design pattern, along with my friend John Teague. Our goal is to
- Uncover design principle buried behind each design pattern
- Dig bit more into practical application of pattern over just definition and class diagram
- Going beyond “General reusable solution”
- Finally, disclosing why everything you hear about these patterns from your friend is almost wrong.
- Avoiding those silly coupling mistake which gifts you sleepless night just before release.
Here are few important bookmarks, which you might be interested in keeping eye on:
Alternatively, you can subscribe to our RSS feed at
I will soon post about overall outline of this series of blog. In short, as of now, idea is to cross post on both of above space and each design pattern will followed a screen cast which will demonstrate example discussed in the blog. These screen case will be a very good example of pair programming too.
Watch this space… much more interesting to come
Develop smartly :)