The confusion of Design Patterns

I purchased the Gang of Four Design Pattern book almost ten years back when I was just a novice in the field of programming. At that time someone suggested me to have a look into this book. In last so many years, I have purchased tons of books and retired them because of the technology being obsolete or newer versions coming up. However this book has survived and still is one of the book which invariably appears on my desk regularly.

In technical discussions, it is very common to throw names of the pattern from this book and build the discussion around them. I have seen so many so called architects popping the names of patterns before even listening and understanding the problem that is at hand. I would confess today, that I always felt I am missing something in that discussion. I have tried to go through this book many times but let me confess, I always got backfired because of its terse language and its dryness. Of course I am not expecting a technical book to be titillating, but I always found this book difficult than Bjarne Stroustroupe C++. I envy all those guys who I have seen look so comfortable in popping terms from this book.

I have gone through the book many times and I would say that it's a great effort by the writers. The one thing it brought to the fore is to identify the best practices and document them for re usability. One questions though always nags me is that if I do my job of understanding abstraction, encapsulation and inheritance properly, whether or not I will reach to same set of solutions or not. I do not know the answer of this question in this life now as I now understand this patterns a little bit so I would force my solution.

The pattern world has not stopped here and there are zillions more patterns still appearing everyday. It looks that the moment one writes a piece of code twice, and pulls the repetition at a common place, a pattern is declared. It has become a fashion to put the pattern understanding as an important requirement for interviews. And there are people who know the class diagrams of all patterns but still don't have the feel for abstraction, inheritance encapsulation or polymorphism. I am using the word feel as I think this is the word that separates out the coders and the designers.

Now I would delve little deeper into the patterns and would like to bring out the confusion that I always get into. One of the confusion that I always have is that do we really need to have such a lot of patterns. For me whenever the number of concepts I have to deal with is more than five or six, I get nervous. The four concepts of abstraction, inheritance, polymorphism and encapsulation are good for me. It still keeps the fifth and sixth for the Visitor and Observer pattern.

We have creational patterns. We have a factory and we put some more level of indirection and we have an abstract factory. Singleton looks like a factory where I always go to the factory to get my object. Sometimes Singleton looks to be a facade or a proxy to me, where the facade hides the details from me. A builder looks similar to abstract factory with the abstraction removed. It can even be a factory with one more level of indirection in terms of the steps of object creation. Put one more level of indirection it's probably an abstract factory. Prototype is like a factory to create the same type of object. Proxy, Director, Adapter, Facade all look similar to me. Everything is at one level of indirection so we reduce the coupling. Believe me or not State and Strategy also look similar to me. Here the logic is captured somewhat in classes and in Proxy and all, the logic is captured somewhat in methods. And than not sure how different template is from a facade. In template we have to do some pre and post processing so we put the common pre and post processing at a common location and keep changing the state of the actual implementation or change the strategy that is required to call the things in the middle. Chain of responsibility and Iterator are different in intent but in terms of usage, in Chain of responsibility we worry about what the sequence is going to do and in iterator how we are moving in the sequence. And what we do is governed by the command. Interpreter looks a state to me and flyweight is a map. Do I need a heavyweight pattern terminology to save the state of my object at any given point of time. I can just copy the state in a data structure and make sure that the logic of copying is properly encapsulated. Observer and Visitor is something which I think would not be easy to come with if I don't know the GOF book.