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.
- Confusion as to what the GoF are saying.
- Awe at the significance of what it all means.
- Amazement that design patterns are not discussed more and practiced
more.
- Recognition of mistakes within the collection of the 4 or
5 pieces of “literature” that you have by now read or watched.
- 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!)
- Thinking up analogies to everyday situations and other
industries.
- Mental application to software problems you have
encountered and/or problems you are facing.
- Thoughts on how patterns interact with each other.
- Ponderings on how patterns could make your GUI, Database
and Middle-Tier Applications more extensible and more robust.
- 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