Me, You and Design Patterns in VB.NET
page 1 of 2
Published: 03 Jul 2006
Unedited - Community Contributed
This article addresses who should learn GoF design patterns and why, and object oriented programming with Visual Basic.
by David Simmonds
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 18040/ 27


This article addresses who should learn GoF design patterns (every software developer in the world) and why you should be enthusiastic about learning design patterns.  Additionally, it talks a bit about the skills you should already have (OO in VB.NET) and talks a bit about why knowing C++ (even the basics) will help you. It also looks at the legitimacy of VB.NET as a language for demonstrating GoF design patterns.  Finally, it deals with what other authors have said about choosing VB.NET (good things).

Who else is the tutorial for?

To study design patterns in VB.NET, you should definitely know VB.NET on a professional level and be quite versed in its Object Oriented language features.  It also makes sense to know a lot of language features, since quite a few will be used in the course of the discussions.  As the Gang of Four (GoF) put similarly in their Preface, “If the first mention of Mustoverride or MustInherit confuses you, then you need to pick up a copy of Programming Visual Basic .NET 2003 (or the 2005 edition).”

That said, when should you learn design patterns?  Without a doubt, learn them as soon as you learn OO and know VB.NET properly.  Design Patterns allow you to understand why the OO language features exist and how to use them.  They solidify the language features you have learned by showing how they are put to good use.  So OO knowledge and Design-patterns reinforce each other quite a bit (some people would say they are one and the same).  I do not believe you should learn VB.NET this year and learn design patterns 2 years later.  My vice principal in high school used to say that when he is teaching someone to play Table Tennis, he prefers to work with beginners than those who have learned it badly or wrong.  I do not know why that stuck in my head for over 20 years. More than likely it is because it is true.  I think it is much better to learn good OO design principles through learning design patterns than to spend the next 5 years “paying your dues” by fumbling through bad OO designs, only to end up finally unlearning all the bad OO design habits and then trying to superimpose design patterns on top of the mess.


What patterns should mean to you as a Software Developer, or “Why you should be obsessed with patterns when you know what they are?”

I had a boss once who compared clumsy actions to doing surgery with a machete.  I venture to say that if you design OO systems without design patterns, then you are doing surgery with a machete while dancing on stilts.  You might actually be putting lives at risk in an indirect way because you are designing code and you will not be around to maintain it forever.  When a developer goes in to maintain your code, some clients who use the code will still work and some will not and you may not be sure who is doing what.  For life-critical systems, disasters can happen as a result!  

This is why since discovering design patterns I have become literally fanatic about it; living it, eating and breathing it.  Thinking about how patterns interact with each other, with the GUI or with database, I reflect on patterns in threads and I obsess about real life examples of various patterns.  I am literally obsessed and you need to be too.  Every design team needs to have a lead developer who is thoroughly immersed in design-patterns and all developers need to understand the concept, intents and motivations, while having pattern literature at hand so they can implement and maintain the code designed in patterns by the lead developers.

The GoF saw the software development train running off the track, waved the DP-lantern to signal the way and, in doing so, have earned a hallowed place in the annals of software development.  But something was still wrong and it shows the problem with modesty.  They should have forced it down every software developer’s throat as that is the absolutely only way to design software.  Call me a zealot and you pay me a compliment because I will stand in front of this train and let it run me over before I stop waving this lantern.  Every self respecting university’s computing department should have 5 copies of the GoF book.  If every Computing department (in universities and workplaces) has a book that they subsidize or give away free, the GoF should be it.

The GoF speak about having an “aha” experience when you discover design patterns.  What a wonderful understatement.  I personally hope you have an “Oh my God! You mean they actually design software without them?” experience when you have the first clue of how they fit and what they represent.  I wish the GoF had even revisited the design patterns in something like JAVA when it came out.  I feel in 5 years time when the development community really wakes up and understands the importance of design patterns, we will have a certification for OO-Languages and Design Patterns, which is similar and possibly equivalent to CISCO’s CCNA.

ISO, IEEE and ECMA and the W3C will want a piece of the action too, mark my words.

The subject takes a considerable effort to learn, but leaves you feeling extremely confident and able to visualize solutions.  It also empowers you to approach problems in the most structured and flexible manner.  Trust me, learn design patterns and you feel like you have put on some sort of power-glove.


Knowing C++

It is not that I am feeling extra controversial, even though controversy is something I do not shy away from, but I am going to say something very controversial here.  You can not become a design patterns expert without becoming at least “highly-conversant” in C++.  I say this because without reading the GoF book yourself and understanding the nuances of C++, you will be like the person trying to become an expert on French Literature by reading critiques written in Italian by a Jamaican author.

When I understood the implications of patterns, I forced myself to learn C++ so I could understand them properly.  I actually went on a sort of pilgrimage back to C++ (which when I revisited it recently, I remembered why I thoroughly avoid it).  By being able to read the GoF book uninterrupted, I felt like someone who finally fulfils his longing to take off his shoes and run on the beach and feel the sand between his toes.  That is why I learned C++ properly this time.  I wanted to feel the patterns pressed up against my brain.  

When you know C++ for yourself and can read the GoF book first-hand, you feel the way some of those early biblical translators must have felt when they decided to learn Greek and Hebrew so they could do a first-generation translation/interpretation of the bible into their own language.

For this reason I have included a brief C++ code reading guide (CORGI) since I expect you to read the GoF book and get a first-generation understanding of the GoF’s thinking on the pattern.  Having done that, then read my tutorial for an illustration of how to implement the pattern in VB.NET.


How will your thought process on Patterns evolve?

They say the grieving process has several stages.  I would like to think that as you learn more about patterns, experiment with them and think about them in your spare time, you will probably go through stages somewhat similar to those listed below.

  1. Confusion as to what the GoF are saying.
  2. Awe at the significance of what it all means.
  3. Amazement that design patterns are not discussed more and practiced more.
  4. Recognition of mistakes within the collection of the 4 or 5 pieces of “literature” that you have by now read or watched.
  5. Arrogance in how much you know and a sense that your boss is not as great as you once thought.  (Software Architect Bosses, you better get busy learning design patterns so you can stay ahead of your employees!)
  6. Thinking up analogies to everyday situations and other industries.
  7. Mental application to software problems you have encountered and/or problems you are facing.
  8. Thoughts on how patterns interact with each other.
  9. Ponderings on how patterns could make your GUI, Database and Middle-Tier Applications more extensible and more robust.
  10. Thoughts on the consequences of Security and Performance in individual patterns.


Do not worry if you do not understand your first reading

Someone once told me you never forget your first car and it will always be the best car you ever had.  For me, the car I will never forget and will always be extremely fond of is the one I learned to work on.  It may sound contradictory that you should love something which you have to maintain a lot, but it is true, the attachment grows.

The GoF suggested that Design Patterns is a topic which you need to romance with your brain and allow your brain to romance in return.  It must be a requited love.  As they pointed out:

“Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing!”

I know this for sure though, once you have learned design patterns properly (by about the 3rd to 4th piece of good literature/material you study), you will never forget where you learned about it.  Hopefully, it is a good first experience.  If you read Gabriel Garcia Marquez’s Love in the Time of Cholera you will understand how I felt.  Coincidentally, my first time was in www.LearnVisualStudio.NET.  But I revisited the Object-Oriented Section (2100 series) for a general revision of VB.NET’s OO language features.  I sought the advice of an old sage: a C++ tutorial on the Internet.  Finally, I revisited the pages of GoF and my eyes now accustomed to the light that coped through the cracks, I was able to see it in all its glory. Now I must tell others how wonderful it is.  Thanks for meeting me here in this tutorial so I can do just that!

My Approach: Recognizability

As the GoF said:

"Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent"


I interpret this to mean that patterns must be recognizable.  For example, let me say that I can go to any “radiator-specialist” who has a blow torch and a spanner.  In 20 minutes he can fix any leak in my radiator and I will be on my way.  This is because radiators are built in a way that is instantly recognizable to people who maintain them.  They may come in different sizes, bolt on in various ways and come with one fan or two, but the structure is very recognizable.  So as much as there are bright young engineers who must have dreamed up super-efficient ways redesigning the radiator, being recognizable takes priority because someone else has to install and maintain them.

Imagine this: The countdown guy at NASA meets a nice French girl.  So one day in the middle of the rocket launch, he feels creative and starts saying "T minus tres, T minus dos, T minus once."  The familiarity of the launch sequence would be lost and he would throw off everyone in mission control!  Or picture that you are driving along some boulevard.  A traffic engineer who is overly gifted with initiative makes the unilateral decision to replace the red in the traffic lights with fuchsia because it can be seen from further away.  Can you imagine the number of accidents and court cases?  Sure some parts of the patterns can be tuned for better performance or made to take up a slightly smaller footprint.  The GoF guys themselves admitted this very thing as described below.

“Design patterns should not be applied indiscriminately.  Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and / or cost you some performance”

In my humble opinion, in these days when the average “pen” comes with a 3” x 4” touch screen and a 300MHz CPU inside (a hand-held device), a performance hit is well worth it to preserve familiarity.  I call it pattern-safety (if the compiler’s ability to recognize a variable as a particular type is called type safety, then surely we can consider the developer’s ability to recognize a design pattern as the pattern safety).  This is why I am a stickler for faithfulness of reproduction.  Maybe the patterns in this tutorial will not be 100% faithfully reproduced, but I have made every effort to ensure that they are.  Furthermore I have tried to highlight the areas in each pattern which I believe are most susceptible to misinterpretation so that discussion among developers can flourish.

But this brings me to another point - which is that this business of writing about design patterns should not be entered into lightly.  It should be approached with caution and care, with plenty of time on your hands, having read several books and watched a few videos.  You should see the way design-patterns can be mangled at times, seeing the nuances in how they are rendered and very importantly, having considered the importance of getting them right.

Patterns by Numbers

I intend, God willing, to do all 23 patterns.  I believe the reader should be allowed to judge for themselves which one is their favorite and which ones to use due to their relevance to the problem at hand.  Very important is the fact that the patterns reinforce each other, complement each other, juxtapose themselves against each other and, taken as a whole, give a sense of overlap which leaves the reader with a sense of completeness.

Even if all patterns are important, which are the most important?  I believe that why the GoF listed them in alphabetical order is significant.  I think the implicit message here is that not one in particularly is more important than another.

An Academic approach

It is true, you are going to find that my approach is academic and there is no overarching sample application.  You will see many inconsistencies in my approach.  After-all, it is not Addison-Wesley, Apress, MacMillan Microsoft-Press, Sams, Wiley or Wrox (though I would not mind).

There will be times you will wonder why I used a datareader instead of a command object or some such inefficient approach to accomplish something.  You will disagree with my approach of interpreting or rendering a pattern on occasion (hopefully not too frequently).

As far as being an expert or absolute authority is concerned, I am not claiming I am. This is why one of the first things I do is send you to the GoF and one of the last things I do is send you to other interpretations/renderings of the pattern that I think are worthy of a read. Because in any case, there are one or two patterns that the GoF themselves did not set down concretely.

As far as being a VB.NET expert is concerned, if you know a better way to do something in VB.NET then be my guest and implement it in your code.  Remember, this tutorial is about Design Patterns in a VB.NET context.  So by far, the most important language features are classes/interfaces/MustInherit (abstract) classes, inheritance, method overriding/shadowing, scoping, etc.; in other words, VB.NET Object oriented features.  If I incorrectly use an abstract class instead of an Interface, then I am off the mark.  If you notice an inefficient approach in ADO.NET, Win-Forms, multithreading, securities etc, then you are nit-picking

View Entire Article

User Comments

Title: What is this   
Name: Ashish Manasvi
Date: 2008-04-11 7:23:54 AM
I think people should post their article with proper headings. The heading of this article and the content are entirely different.
Why we have such things on this good website??
Title: Complete time waste   
Name: Deepak Sharma
Date: 2006-07-11 1:51:29 AM

I thought we are speaking on design patterns but here we see people trying to defend to c#.

With good site like yours, you should be careful having articles.
Title: Where's the beef?   
Name: Whoever
Date: 2006-07-06 2:58:14 PM
I was waiting for the actual discussion about each (or any) of the design patterns, utilizing VB.NET, but... Where is that? This seems like an article stating, "This is what I'm going to talk about, and why" but then doesn't actually go on to discuss any of that. Am I missing something? Is there a hidden link to a URL which DOES discuss any/all design patterns using VB.NET? This article does not seem to include any.

Product Spotlight
Product Spotlight 

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

©Copyright 1998-2024  |  Page Processed at 2024-07-23 4:36:53 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search