IT.Wox, always

A colleague of mine asked me a question few days back: "If an application is created using the correct design patterns, does it ensure that the application would be bug/performance issues free?"

The answer to the question gave me an idea to put in a series of articles to look at what are design patterns, what design patterns can/can't do & hopefully get some interesting dialog started with you readers about your experiences & inputs.

Let us start this journey with a small step in understanding a few definitions regarding design patterns, and look at what design patterns are all about at a very high level. The subsequent articles will focus on details of each pattern & a few scenarios where we can use these patterns. 

What is a design pattern?

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design" - (Wikipedia, 2008) 

IMHO, a design pattern is a probable way to solve a design problem in software. I use the term "probable" because even though a design pattern might "seem" to solve the issue you are facing, you still need to analyze the problem & ensure that the solution/pattern offered is valid in the context of your development effort.

This judgement is acquired only by experience in either using the pattern successfully or having burnt your fingers in the process. Experienced Architects, Designers & Developer will tell you that even if you have had used a pattern many times in your previous projects, you will still need to evaluate using the pattern in your current project simply because the requirements/project environment/time-of-the-day is different from the last time you used it.

"Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges." - (Data & Object Factory, 2008)

The key word in the definition above is the idea of a "communication platform". A design pattern not only helps in communication between objects, but also provides a communication platform in discussing your ideas with your peers.

For example, it would be easier in telling someone that you are planning to use a Facade pattern instead of a MVC & they would instantly know the "structure" of what you plan to do. So you could directly get into a discussion about the merits/demerits of using a particular pattern & focus on what meets your business requirements rather than spend time explaining what you plan to do.

Note: The above statement is assuming that the "someone" also understood design patterns; else you can always point them out to this series for more information

What is NOT a design pattern?

These are a few items that come to mind & I will keep updating this list if you have some more items to add here. So, here goes:

• Design patterns are not architecture patterns - design patterns specifically deal with the problems at a software design (object creation, communication & behavior) level, while architecture patterns deal with the problems at the software engineering (communication, operation, maintenance, enviroment, physical/logical layers in the application) level
• Design patterns are not solutions to your problem - design patterns are generic solutions to generic problems. Your application is not a generic application, so if you need to "customize" a design pattern to solve the specific problem you are facing. This customization would be valid only within the confines of your application to address that specific problem. You will need to start this analysis all over again in a different problem/project.
• Design patterns are not algorithms - design patterns are not implementations, they are only a "framework" for a solution, while algorithms are implementation of a problem solutions to a problem. So, while algorithms may be directly used in your application (For example, an algorithm for a bubble sort), design patterns need to be tailored for your application
• Design pattern is not a hammer looking for a nail
• Design patterns are not answers looking for questions (this is a good quote from my friend & colleague Vasanth)

Why do I need design patterns?

Frankly, you could continue with the rest of your programming life without knowing a single design pattern & you could do just fine. As long as a piece of software meets its business goals, who cares what it does under the hood, really?

Then again, do you see a productivity benefit in using a proven development paradigm instead of re-inventing the wheel (unless the wheel was square, ofcourse)?

Would you prefer eliminating those hard to fix logical bugs in your application by using a standard template of avoiding such issues?

Do you like to appear cool (or a nerd, depending on the audience) by explaining the nuances of MVC/MVP patterns, or start a flame-war if MVC is really a design pattern or an architecture pattern?

If your answers to the above questions is a resounding YES, then unfortunately you do need to know what design patterns are.

On the bright side - you now have a new way to screw up your code & people might actually understand where you screwed up & help out with solutions!

Great, when do we start?

If you still didnot notice, we are already on our way!

This was the first of the series of articles & I hope to bring out the next one ASAP. Till then, you could go through my previous articles, which really have no connection to this article whatsoever, but interesting enough, I hope.

The Answer

Regading the answer I gave my colleague to his question posed at the start of this article, I realized that my colleague had two positives going in his favour:

1. He realized that all software projects inherently had bugs/performance issues in them - to a detected or un-detected extent
2. He was curious if his new-found knowledge could help him solve these issues