I will try to give a very generalized view of what a Pattern is. This is because it can be interpreted by different people from different backgrounds in different ways. So here is an overly simplified version, with as little terminology as I can :)
Since programming activities have existed for a long, long time and certain problems have arisen over and over again, patterns address some of these problems by offering a solution. The solution can sometimes be standardized and documented. Design Patterns are a result of people learning ways of doing things and constructing guidelines for doing it. They are not fool-proof, nor are they appropriate for every occasion, but they do offer benefit where they fit the problem.
It is not fixed thing - more patterns are being created all the time.
You can create patterns too!
Let's create our own somewhat silly design pattern here quickly (so that you get the idea) -
Lets call it
ExternalAccess.
Reason for pattern: To make sure that whenever a propery is used it uses the rules for the property.
Example (our set always adds a 1)
Property myValue as Integer
Get
Return internalFieldValue
end get
Set
internalFieldValue = Value
+1
end set
end property
if our code inside the class talks directly to internalFieldValue it will not run the code thus not adding the 1.
This is a problem.
the rules for negating this problem:
- The object must have Property Accessors (Gets/Sets)
- All fields must be private to the class.
- when internal code (code within a member of the same class) uses the property it must use the property and
not the field.
So in this simple example, all we have really done is provided some guidelines, but in a more complex pattern we may also have declared what kinds of objects to create and how to use them.
So, Design Patterns are kind of like a cross between templates and coding guidelines for constructing code.
Recognized Patterns are those that have been accepted by the general community of architects and developers to be useful. These include patterns like Abstract Factory and Facade.
Most of the time, Patterns are relatively language independant, so you can use the same pattern in different languages. Some patterns though have specific ideas about the language. When it comes to .NET, C# and
VB.NET patterns will be absolutely the same except for syntax. This is because it has the same ideas about types, classes and the language syntax is for the most part nearly a 1 on 1 mapping. So if you find a pattern implemented in c# (provided you can read c#) would also be helpful to you.
Here are a few c# and
vb.net links (the c# may be easy enough to get you started even though you are coding in
VB.NET).
http://www.vbdotnetheaven.com/Code/Jun2003/2015.asphttp://msdn.microsoft.com/msdnmag/is...1/07/patterns/
http://www.codeproject.com/csharp/csdespat_1.asp
http://www.dotnetextreme.com/code/SingletonCs.asp
I do not know of any specific
VB.NET centric views on Patterns - perhaps some other reader could contribute some links?
Jonathan Crossland
http://www.jonathancrossland.com
DESIGN Patterns
