Design Patterns in VB.NET
page 1 of 4
Published: 10 Jul 2006
Unedited - Community Contributed
Abstract
This article looks at what are GoF design patterns and how they fit. It mentions who the GoF are and how they came to work on the design patterns. It also deals with the parts of a pattern and the O-O design principles which underwrite them. Finally, it examines the advantages of using design patterns and why you should use them to code every day.
by David Simmonds
Feedback
Average Rating: 
Views (Total / Last 10 Days): 60174/ 119

What are GoF Design Patterns

Design patterns represent repeatable solutions to common problems found in designing object oriented systems.  They represent optimal (though not perfect) ways of arranging classes and objects together and assigning to each class responsibility for instantiating, interacting with, composing other classes and passing messages to each other in order to solve a particular problem faced by developers.  Consider a radiator, such as is found in a car.  You might ignore it for a long time, but if you have a “vintage” automobile, then driving on a hot day in bumper-to-bumper traffic (a radiator’s worst nightmare) you might notice your windshield getting an unscheduled “steam-bath.”  So, you call your favourite mechanic and you get the car to his garage.  Then, having a lot of time on your hands, you finally pay some attention to the unassuming, but very vital piece of equipment that thanklessly cools your car engine day by day.

The radiator is a vital component in your car and is composed of parts which interact to achieve the cooling of your car’s engine.  In the same way, a design pattern represents an arrangement of classes with an assignment of responsibility to each, which represents the way to solve a particular problem. This arrangement is easily recognizable to the initiated and is easily reproducible in other situations.  It is also easy to extend and maintain the pattern by those who understand its inner workings.  Every self-respecting mathematician understands that math problems have patterns which comprise participants that collaborate (quadratic equations have cubes and squares that are solved by factoring, simultaneous equations have two equations, each with two instances of the variables to solve for and geometry problems have lines and angles and are solved with cosines, sines and tangents). The goal of this tutorial is to have every single O-O programmer in the world be initiated into the structure and workings of design-patterns.

 

Origin of Design Patterns

There are hundreds of design patterns that are broken down broadly into design patterns, concurrency patterns, transactional patterns, web patterns and other categories.  So design patterns are by no means the only category of patterns.  No one is saying that the Gang of Four (GoF) have cornered the pattern market.  For that matter, it should be pointed out that the GoF did not even create these patterns.  They largely existed in O-O systems before.

In 1994, four guys, now all PhDs: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (who died of cancer November 24, 2005) came together in order to write a book that was built on Erich’s PhD thesis.  It was published as “Design Patterns, Elements of Reusable Object-Oriented Software” (Addison-Wesley, ISBN 0-201-63361-2).  On the way to being published, it was presented to several O-O conferences and eventually in book form became known as the “bible” of patterns.  The software development community also affectionately nicknamed these four pioneers the “Gang of Four” or GoF (folks concerned about misguided religious fervor should note the common “o”).  So we have a “Gang” which is responsible for a “bible.”

The GoF patterns represent the core of design patterns.  When you study them and look at other patterns, you see tremendous similarities which make you suspect that you could get by with focusing on the 23 they described.  They might have tweaked them a bit to improve their robustness, but they were pre-existing and the GOF simply documented them.  In fact, a requirement for a pattern being documented was that it already existed in several applications.  What the GoF actually contributed was their methodology for cataloging them, which is impeccable and introduced the well needed thought process required to mull over, digest and ruminate on design patterns in order to make them a part of your vocabulary and incorporate them as the centerpieces of your design efforts.

So the GoF simply did for design patterns what the Bauxite companies did for Aluminum. The Bauxite companies did not make Alumina, but they engineered ways to find it, unearth it, process it, purify it and turn it into Aluminum - a metal that the GoF would have appreciated on (I assume) their trips across continents, since it is used in the instantiation of the structures of Airplanes and Cars due to its lightweight coupled with its tendency to behave very robustly under pressure.  The unfortunate thing is that scientists are usually poor businessmen (literally) and usually lack branding and marketing skills.  I ask myself what the difference between CISCO and what GoF Patterns could have been or still could be?  The answer I come up with is nothing.  In fact, let me be (one of?) the first to predict that there will be GoF certification in the future.  GoF centers will be all over the world, complete with logo and quarterly results.  I know PhD's abhor money.  But after all, the Bauxite companies did not create bauxite either.  And believe me, in Jamaica, when you work for a bauxite company, you do not exactly beg for a living.

As for the other design patterns and other categories of patterns, if you are interested in the hundreds that exist then do not stop here, you are welcome to go explore.  Me, I specialize in GoF.

 


View Entire Article

User Comments

Title: Code samples   
Name: Mike Angelastro
Date: 5/12/2008 10:13:13 AM
Comment:
What is a good source of VB .NET code samples for the design patterns?
Title: How do design patterns fit with SOD/SOP   
Name: Mike Angelastro
Date: 5/12/2008 10:10:30 AM
Comment:
How do design patterns fit with Service Oriented Design/Service Oriented Programming? The underlying principles are similar.

Another metaphor is a schematic diagram of an electronic circuit or logic circuitry. These explain how item is put together.
Title: Response to Estevez - Part II : Philosophy of Design Patterns   
Name: David M. Simmonds
Date: 5/21/2007 3:26:11 PM
Comment:
On the other hand, design patterns do have a very philosophical basis. The philosophy which applies to design patterns (and undergirds many religions) is that if you delay gratification (in this case the implementation of the software) and put more work into the design upfront, then you reap less pain overall and in the long run (maintaining one aspect of the system does not mess up other parts of the system). Modifications can be done painlessly and cheaply without testing every other feature in the software. Hence programmers would be involved in less "software crises".

Anyway, watch for the day when the due diligence (which is done leading up to a corporate merger/buyout) includes a software design review which determines whether the mergee has software built using design patterns. At that point, you are going to see just how tightly intertwined philosophical issues and Dollar issues can be.
Title: Response to Estevez   
Name: David M. Simmonds
Date: 5/21/2007 2:04:47 PM
Comment:
In response to Estevez:
"I think Design Patterns are an philosofic part
of programming, can't see any worth of using it."

My response is, TRUE !!! Especially if you work in your IT department's Pre-Requirements-Change unit (the Software-Development counterpart of the Pre-Crimes unit as portrayed in "Minority Report")

In other words, if you are a precog and you can read the user's minds from the day you collect User Requirements in order to do your Software Specifications, then you will never need to modify functionality in your software or add features to it. So you are right, why spend all of that effort designing the software to make it easy to extend or modify when it never needs to be modified or extended?
Title: Art of programming   
Name: Estevez
Date: 5/18/2007 5:11:20 PM
Comment:
I think Design Patterns are an philosofic part of programming, can't see any worth of using it.
Title: nice Analogy   
Name: Amos
Date: 5/10/2007 6:05:32 PM
Comment:
The way to use a car and car industry to illustrate patterns and software kick-ass.
Title: Perfect WHY article   
Name: Vin
Date: 4/13/2007 3:58:52 PM
Comment:
Everyone will be motivated to learn about design patterns after reading this article
Title: Easy to Read   
Name: Mayank
Date: 2/16/2007 11:46:26 AM
Comment:
The article is very well written & informative. It deals with a complex subject in a very lucid manner. Expect more such great articles in future.
Title: Look forward to more in the future   
Name: Ben
Date: 1/29/2007 6:41:04 PM
Comment:
Great article, I enjoyed it very much. Hopefully there will be follow-up articles with even more detail!
Title: Fantastic :)   
Name: Kris
Date: 1/26/2007 7:40:12 AM
Comment:
Very elegantly described and introduced to design patterns.
Probably also listing what excatly are 23 patterns defined, would make this article more informative
Title: So cool   
Name: Luis Vega
Date: 1/23/2007 5:19:38 PM
Comment:
Excellent Article, I want to read more.
Congratullations
Title: Good Analogies   
Name: Ali
Date: 1/18/2007 5:01:33 AM
Comment:
Great article! Very very nice real world examples. I am expecting great articles regarding this article in future.
Title: Solar System   
Name: Miri Davidian
Date: 1/15/2007 9:17:29 AM
Comment:
Dear Sir,

I have a question.
I would be grateful if you would help me.
What would be the design patterns solution for solar system?
The Sun, is obviously singleton.
The plans are obviously factory.
But, when it becomes to the stars,
I wonder what they are.
On one hand, the stars are factory for the sun;
on the other hand each is a singleton for his own plans.
So, what are they?

Many thank in advance,
Miri
miridavidian@gmail.com
Title: very good   
Name: Rushikesh K Khairnar
Date: 1/7/2007 1:35:09 PM
Comment:
Simple and informative
Title: Nifty   
Name: Denny Jacob
Date: 12/27/2006 3:48:46 PM
Comment:
Simple, flowing and not one wasted word. I wish more of us had this pattern of writing!!!!
Title: Very Good   
Name: Pandi
Date: 12/26/2006 12:01:56 PM
Comment:
It was very good to a new person who wants to know about Design patterns.
Title: many thanks   
Name: Monica
Date: 12/18/2006 11:58:07 AM
Comment:
clear view of how design patterns came to light!
Title: Tanks   
Name: Shaik Kaleelur Rahman
Date: 12/18/2006 5:32:27 AM
Comment:
Very Nice Article
Title: Well Done - Three Cheers   
Name: Rajeev Gopalakrishnan
Date: 12/12/2006 4:10:56 PM
Comment:
Wonderful, my friend, wonderful! I can't say that any more louder!!
Title: cool   
Name: shubha N
Date: 9/11/2006 5:44:18 AM
Comment:
this artical is very informative
Title: very informative   
Name: gowri shankar
Date: 9/11/2006 5:42:53 AM
Comment:
it was very informative good work
Title: Nice   
Name: Veeru
Date: 8/25/2006 8:58:23 AM
Comment:
This very nice,very useful to every one,and this is a wonderful job......
Title: KISS   
Name: George
Date: 7/27/2006 11:34:53 AM
Comment:
Keeping it Simple and Straight. A very refreshing article, waiting to see more of this... Great job
Title: Plain and Informative   
Name: Mehdi Anis
Date: 7/21/2006 3:51:23 PM
Comment:
I enjoyed reading this article. nicely written delivering good information. Thanks.
Title: Cool   
Name: Ed
Date: 7/18/2006 7:48:51 AM
Comment:
Great Article. Very useful. Wonderful job
Title: Cool   
Name: Ed
Date: 7/14/2006 6:03:56 PM
Comment:
Great Article. Very useful. Wonderful job!!!

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2014 ASPAlliance.com  |  Page Processed at 9/1/2014 7:13:41 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search