Click here to Skip to main content
13,590,511 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


43 bookmarked
Posted 28 Jun 2008
Licenced CPOL

Design Patterns - A deep dive: Part 1

, 28 Jun 2008
Rate this:
Please Sign up or sign in to vote.
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?"


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:

  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.

Since two positives still make a positive, I replied: "Yeah, right!"


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Sunny Chaganty
IT.Wox, always
India India
Sunny is the founder of IT.Wox, always ( - a web application design, development & consulting company

You may also be interested in...

Comments and Discussions

GeneralWao .. Pin
manas10-Sep-09 23:03
membermanas10-Sep-09 23:03 
RantBoring......but nice try! Pin
drm99889126-Jul-09 5:48
memberdrm99889126-Jul-09 5:48 
GeneralThanks for your comments & feedback Pin
Sunny Chaganty2-Jul-08 7:10
memberSunny Chaganty2-Jul-08 7:10 
GeneralWell... Pin
Uncle Serge1-Jul-08 22:38
memberUncle Serge1-Jul-08 22:38 
Generalgood article Pin
hongshun_19821-Jul-08 21:21
memberhongshun_19821-Jul-08 21:21 
GeneralGood Article Pin
MoRiKa1-Jul-08 21:17
memberMoRiKa1-Jul-08 21:17 
Generalnice one Pin
Haja30-Jun-08 21:08
memberHaja30-Jun-08 21:08 
GeneralRant :) Pin
Neni-san29-Jun-08 22:06
memberNeni-san29-Jun-08 22:06 
GeneralRe: Rant :) Pin
Sunny Chaganty30-Jun-08 6:09
memberSunny Chaganty30-Jun-08 6:09 
GeneralA usefull article. Pin
adamzhang28-Jun-08 20:26
memberadamzhang28-Jun-08 20:26 
Generali hate links Pin
lemravec28-Jun-08 9:56
memberlemravec28-Jun-08 9:56 
GeneralRe: i hate links Pin
Sunny Chaganty28-Jun-08 17:28
memberSunny Chaganty28-Jun-08 17:28 
GeneralGood start Pin
Ray Cassick28-Jun-08 8:48
memberRay Cassick28-Jun-08 8:48 
GeneralRe: Good start Pin
Sunny Chaganty28-Jun-08 17:20
memberSunny Chaganty28-Jun-08 17:20 
GeneralRe: Good start Pin
Juy Juka30-Jun-08 19:56
memberJuy Juka30-Jun-08 19:56 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web04-2016 | 2.8.180618.1 | Last Updated 28 Jun 2008
Article Copyright 2008 by Sunny Chaganty
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid