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