Introduction
A colleague of mine asked me a question a 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 Design Patterns are, what Design Patterns can/can't do, and hopefully get some interesting discussion started with you readers about your experiences and 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 the details of each pattern, and 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)
In my opinion, 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 and ensure that the solution/pattern offered is valid in the context of your development effort.
This judgment is acquired only by experience in either using the pattern successfully or having burnt your fingers in the process. Experienced architects, designers, and 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 the 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 keyword 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 an MVC, and 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 and 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 understands Design Patterns; else, you can always point them out to this series for more information :P
What is NOT a Design Pattern?
These are a few items that come to mind, and 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 problems in the software design (object creation, communication, and behavior) level, while architecture patterns deal with the problems in the software engineering (communication, operation, maintenance, environment, 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 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
implementations of a problem solutions to a problem (update: thanks to Neni-san for pointing this out in the comments section). 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. - A 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 and 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, and 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, of course)?
Would you prefer eliminating those hard to fix logical bugs in your application by using a standard template for 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 on 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, and people might actually understand where you screwed up and help out with solutions!
Great, when do we start?
If you still did not notice, we are already on our way!
This was the first of the series of articles, and I hope to bring out the next one as soon as possible. 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:
- He realized that all software projects inherently had bugs/performance issues in them - to a detected or un-detected extent.
- He was curious if his new-found knowledge could help him solve these issues.
Since two positives still make a positive, I replied: "Yeah, right!"
