This week I'll be posting about how to implement design patterns in VB.NET. Before we can look at that though, we need to discuss what a "Design Pattern" really is at its simplest form, and why we'd consider using design patterns.

There's much discussion about "design patterns", and some people might think that patterns are something only high-level architects discuss, or that you have to be x-number of years experienced. The reality is that design patterns aren't complicated and can be utilized by any level of developer. In fact, the only real pre-requisite that you need to have is an understanding of object oriented software development and how ref and value types work in the .NET framework.

So let's start with a definition of what a design pattern is:

"A design pattern is a solution to a problem within a context."

That's it. Simple eh? All a design pattern does is describe a solution to a problem that has been encountered over and over, and where the solution has been shown to work time and time again. The key word of that definition is actually context. You don't just use design patterns "just because"...doing so doesn't make you more technical or more geeky. You use design patterns because you have a specific problem that you need to solve.

Another benefit of design patterns is that object oriented software developers now have the ability to talk in a shared, common language. Regardless if you're using .NET or Java or any other OO language, a pattern is the same across the board (although implementation will obviously differ somewhat, but the overall concept is the same).

So now that we understand what a design pattern is at a high level, my next few posts will be looking at some very well used patterns out in the wild and how you can implement them in your VB.NET applications.

D