Hot on the heels of my devastatingly fantastic post on an implementation of the Snapshot Pattern, I give you my next piece du resistance. In this little post, I'd like to delve into the Specification Pattern.
So what the heck is it? Matt Berther provided a pretty good introduction
where he states:
It's primary use is to select a subset of objects based on some criteria...
That pretty much sums it up. What we want to do is extract out a specification for a subset of objects we might be interested in. We do this by creating specification objects.
You'll see something like this in a lot of applications:
This is fine in small doses, but your definition of a highly priced sale product might change over time, and we want to avoid having our logic for what IsOnSale and what a highly priced object actually is sprinkled throughout our code. One way to avoid this is to extract our logic into a Specification object like so:
Now the first loop I wrote can be written like so:
This is a slight improvement... There's actually more code to write, but now we can separately unit test each specification we create, without worrying about the loop:
Ok, so that's interesting, but we haven't even gone halfway, here. Why don't we refine that loop I wrote to use the new Generic collections in .NET 2.0:
Wow, now there's some serious savings on lines of code. "But you're missing the bit about the high priced products from the first example!?!" I hear you saying. Fear not, let's extract that into another specification like so:
We're still left with one problem, though. How do we tell the generic list of all products that we want the products that are both on sale and over a certain price? Let's try extracting our functionality into a Specification superclass first. This is what our ProductOnSaleSpecification and ProductPriceGreaterThanSpecification will inherit from. Once that's over with, we can create a CompositeSpecification, which is abstract, and allows us to pass in the left and right sides of a specification "equation." We can then implement yet another subclass (this time of CompositeSpecification) that we'll call AndSpecification. Here it is:
Now our original loop that looks for highly priced products that are on sale looks like this:
We're getting there, but we're still not done. The code we just wrote is soooo .NET 1.1. Let's get fluent with our interfaces and add some sweet sugar to our Specification base class...
I've just added some convenience methods to Specification that will let us chain together any specifications we create. Therefore, our original loop ascends to a new level of sexiness...
For the "slow" ones in the class I've put up a pretty picture for you to look at, while the rest of the class downloads the code, complete with unit tests.
