Note: This is another pre-amble post before we actually look at implementing design patterns in our code. I mentioned some of these ideas in an earlier intro post to design patterns, but I wanted to take some time to dive deeper and draw out in more detail the points I was trying to make.

Sometimes design patterns can become buzz words developers will use. Maybe they think its vogue to be able to drop in terms like facade, proxy, adapter, observer, etc. in their discussions for the same reasons that some people like to use big words to make them sound smarter.

Doing so misses the point of what design patterns are supposed to provide though. Before we talk about design patterns, let's talk about patterns in general so we get our heads around the concept.

Patterns are a way of communicating a repeatable concept that has been tested and proven. They allow us to remove ambiguity in our requests by using a common language that the sender and receiver both understand. Let's consider some real world examples:

How often do you walk into a McDonalds and say "I'd like two all beef patties, special sauce, lettuce, cheese, pickles, onions, and all on a sesame seed bun."? You don't...you tell the person you want a "Big Mac". A "Big Mac" could be thought of as a burger pattern: it points to a certain way to create a burger. It also is a shared term that's part of the language used when in a McDonalds.

I was traveling with my wife in Quebec a year or so ago, and we drove from Montreal to Quebec City. On our way back we stopped in this small French town...and I mean FRENCH, as in English was *not* an equal opportunity language. We walked into McDonalds and I figured that my French was good enough that I should be able to order from the menu. After asking the girl at the counter if she knew English (which we got a hand motion to suggest she was shaky on it), I decided to wow both my wife and this counter girl with my command of the French language.

"Numero une si-vouz-plez" (as in Number 1 which is a Big Mac meal)

She looked at me like I had just spoken Swahili. I panicked for a second...this could only get worse...until my wife rescued me.

"He wants a Big Mac meal"

The counter girl smiled and nodded and realized what it was I tried to order in my horrible attempt at French. Even though neither of us understood each others language, we did understand the pattern of what "Big Mac" meant.

Design patterns are the same way. Design patterns allow us to communicate established designs using common terms who's representations across OO languages may change in implementation but not in basic design.

But here's the real important thing about design patterns, the one thing that you *must* understand about how to use them properly:

Each design pattern is a solution to specific problem in software development.

That's important, because although design patterns are there to help us, that doesn't mean we should or have to use them. Design patterns are in place to make our lives easier for when we encounter the situations they solve. Or in other words, what the context of the problem is.

You don't just use a dovetail joint in carpentry for every situation...only when its warranted. The same goes for design patterns. Have you ever heard someone say "Oh, we should implement a Facade layer here!" Well why? A facade is meant to make interaction with complex subsystem(s) easier. Do you have complex subsystems? Are you just interacting with a tier that you're creating as part of your current application? Does the true idea of what the facade pattern means really make sense?

As we go through the different design patterns that are in the wild, we'll talk about where you'd use them and what problems they solve.

D

Before we get into any nitty-gritty about design patterns and implementation, we need to discuss some language-agnostic terms. I know, I know: But I thought this was a VB.NET blog? Well, it is. But you still need to understand the reasons *why* you'd implement your code using the patterns we're going to get into shortly.

So peppered throughout my next few posts will be some entries discussing terms relevent to helping you the reader understand what's going on and why certain things are coded the way they are. Let's begin with the first one: Single Responsibility Principle.

Single Responsibility Principle (or SRP as I'll refer to it for the rest of the post) is the idea that an object has only one reason to change. By change, we're talking about actually changing the code base of the object.

So for example: you have an order object that records items purchased and also calculates the taxes. This would violate SRP, because a change in either the way items are tracked or in how the calculations are done would mean there are more than one reason why this class could change.

This can sometimes be a difficult thing for people to grasp because it changes how you think about your code. For the longest time, I've always been under the impression that your business objects (like Customer or Employee) always contain everything from properties to reveal certain data of the class to methods to act on that data to functions that allow for saving to the database, including stored proc names, parameter names, etc.

But SRP forces you to think differently. It forces you to say "Look, if each object you have is supposed to be responsible for only *one* reason why it might change, then you can't go throwing all this functionality into just one object." And when you think about it, it makes sense: why would we want to load our domain objects with so much extra code that it becomes a maintenance nightmare?

There's a great article (which is also nice and short...very to the point) on ObjectMentor.com that you can read that talks a bit more about SRP (click here for the page).

So keep this principle in mind as we start to discuss the design patterns, because adhering to this and understanding the principle will make the example code that much more enlightening.

D

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

Welcome to my new architecture and design blog here on 1<3VB.NET! Thanks to Chris for letting me make a new home here. I'm still going to be posting to my GWB blog, but this will be a *pure* technology blog, with code examples, discussions around architecture and design, and of course VB.NET.

Over the next few weeks I'll be posting on topics like design pattern implementation and how the new 3.5 technologies play a role in your application planning.

So add me to your RSS and let's get ready to plan apps the VB.NET way!

D