Lecture thumbnail 0:00 / 0:00 I want to show you yet another example of the composite design pattern.
And this time around, we are going back to an example that we looked at at the very beginning of this
course where we talked about the open close principle and the idea of the specification pattern, which
once again, I’ll remind you, it’s an enterprise pattern.
So it’s not the central topic of this particular course.
But what I want to show you is I want to show you where the composite design pattern comes into play
here as well.
So just to recap of what we’ve seen before, basically we have a situation where we have some sort of
interface or abstract class and it’s called a specification.
And the idea here, I’m making it an abstract class, by the way, because I want it to have that operator
and but it could be an interface.
So we have this idea of a specification that gets satisfied by a particular object of type T, whatever
that T happens to be.
So if we’re filtering products, then that object of type T, that could be a product, for example,
or it could be something else.
And then on the basis of that, we are making combinators, we are making, let’s say, an ad specification.
So if you want to check whether a product fits two particular criteria first and second, then you can
make an ad specification.
And that’s what we did in the example that we looked at when we talked about the open closed principle.
But now I want to show you how we can slightly change this example and make use of the composite design
pattern.
Because after all, what really happens here with the ad specification is that you’re combining other
specifications.
So an ad specification is what you would typically call a combinator.
So it’s something which combines other things together.
And the choice of having two elements first and second is completely arbitrary.
Here we don’t have to have first and second, we can have something that’s a bit more complicated.
And yes, you will introduce another base class and this base class would be called a composite specification.
So let’s take a look at how we can actually build such a class.
So I’m going to have an abstract class.
Notice it’s abstract, so you cannot make an instance of it.
And it’s going to be called a composite specification of T and it’s going to either implement or inherit
from i specification of T.
Now, notice my naming here isn’t perfect because there is an I here and it’s not an interface, it’s
a class.
But that’s not so important for this particular demo.
So what is the composite specification all about?
Well, basically it just keeps a collection of specifications.
So that’s the classic composite design pattern.
You have a thing which exposes the interfaces of a single object while at the same time not really being
a single object.
So here, if we make a constructor like so, then what you would take is you would take any number of
specifications and just combine them together without any semantics, without specifying what you’re
actually verifying.
So here I would use params, so I would say let’s take a params composite.
Well params i specification of t items for example, and we’ll keep those items as a variable.
The only thing that you need to change here is that you need to change this from private to protected
because obviously this is something that we actually want to inherit.
So now that we have a composite specification, what we can do is we can come down into the ad specification
and we can modify it slightly because now we don’t need first and second anymore because all of this
functionality for keeping several elements is actually contained in the base class.
So we can take all of this, we can get rid of it.
And of course we want that constructor.
We want the constructor.
So let me change this to a composite specification of T.
Now I’m going to generate a constructor which calls the base constructor.
So here it is.
Once again you get params I specification which simply initializes the items up here.
And then of course we change is satisfied because now the implementation is going to be different.
So now we take all the items and we ensure that every single one of these items is satisfied.
So we say items all I is satisfied with the value of T.
There we go.
So this is how you would make a combinator for the and operator effectively so you can combine these
specifications and say that I want both of these to be specified.
And similarly you could do an or so instead of all, if you were to use any that would give you effectively
an Or specification.
Okay, so, so that’s easy.
But if you start thinking about other things which are not associative like that, like for example,
XOR, you cannot do this thing with an XOR.
You cannot just just use a chunk of Linq.
You would have to go pair wise.
So you would basically just just take a pair wise elements and you would perform the operation on them.
But the idea is similar and this is once again just another.
A demo of the composite design pattern, because what we essentially did is we made some sort of base
class notice.
It’s an abstract base class that basically contains other constructs, such as the one we are in.
What I mean is that you can now make a composite specification out of several other composite specifications.
So it is possible and that’s what the composite pattern is all about.
It lets you combine things to arbitrary depth.
But at the end of the day, the critical thing here is whether you have a single specification or whether
you have a bunch of specifications, you have the same interface.
That interface in our case is the is satisfied method.
That is precisely the thing that allows you to verify that either a single specification has been verified
or that you have a bunch of them and you apply every single one after another, and then you combine
them in some way, which is why we call this thing a combinator in the first place.
Play Play Play Stop Start Play information alert