Trading off with Design Patterns
Over the last decade or so, any queries as regards designing object oriented software systems would lead to one being advised to read the Go4's book on Design Patterns (Design Patterns: Elements of Reusable Object-Oriented Software). It is without doubt a wonderfully written book and should be in the possession of most software designers involved in the world of object oriented design. But, what happens when an over-enthusiastic reader ends up seeing patterns in every software problem he encounters ?
I had recently come across the a wonderfully hilarious but true write up on when software designers and architects go overboard (http://www.joelonsoftware.com/articles/fog0000000018.html) trying hard to resolve a future problem which may or may not exist - thus compromising on what needs to be resolved NOW. I have been a victim of the same phenomenon - the obsession with "what if tomorrow .....". No, this is not a criticism of the need to look ahead - but it is just to drive home the point that it is important that one does not lose focus on what needs to be solved right now.
The same applies to the choice of design patterns. Over-enthusiastic designers end up creating a problem to implement a design pattern which they may find savy and also as a result of the "what if tomorrow ...." phenomenon. A manifest of this was a case where a product was redesigned to enhance maintainability. The end result was beautifully maintainable code but seemingly not performant enough to be launched in the market. The designers had looked far ahead to the problems of tomorrow to actually think about it's current deployment requirement.It is thus extremely important to 'trade off' between what a customer wants today as an immediate market requirement as against what he is willing to compromise on at a future time.
One needs to be extremely conscious when trying to fit a design solution or pattern to resolve a problem. The Singleton pattern is a very commonly used pattern - and admittedly one of the easiest to understand. You will not have to look too hard into the problem that you are trying to solve to find reasons to implement the Singleton pattern and lot of enthusiastic new designers will jump at the prospect of a chance to implement that chapter in the Go4 book. But, you have got to be sure that there is no thread-safety requirement that the customer has passed on without anyone realizing - which might end up making the 'Singleton' choice look amateurish.
Bruce Powel Douglass spoke at a session at the Infosys campus in Bangalore in July this year where he stressed on how architects and designers need to make a thorough analysis of the choice of design patterns and the best fit necessitated in the system that was under built. He called it 'the selection of patterns using design trade-off analysis'where he explained how the choice of design patterns needed to be weighed against the design criteria that the product was expected to achieve. For example, it was important to weigh the following typical design criteria against the needs of the product.
1. Worst case performance
2. Time to market
3. Memory
4. Reusability
5. Simplicity
6. Safety and Reliability
Now, of a choice of multiple design patterns, each design pattern needed to be rated as against how much it would help achieve each of the above design criteria to help provide some direction on the final choices. A nice elucidation of a structured approach to correct choices in design.
Though Bruce with reference to the world of embedded systems, this approach holds true no matter what system you intend to design. In today's world of instant solutions, doing this might seem slightly unwieldly but it is no doubt absolutely worth the effort.
So, go ahead and master the design patterns as espoused in so many books available, but remember to use it only as a tool to solve a problem that exists. Use it to solve a potential future problem when you are sure that it is not going to compromise the current solution.
