I've said it before and I'll say it again.  I hate UML.  That doesn't mean there aren't pictures that can say 1000 words.  Here's approximately 6000 words on the subject of substitution patterns.  Substitution patterns are patterns where you want functionality to expose a certain interface, but need some sort of bridging logic to achieve that. One nice thing about all of these patterns is that they describe an object.  Patterns that involve several actors are harder to name and explain.  Here, you've got the object that implements the pattern, and the target.  The target never knows anything about...

You might be wondering why I tackled single responsibility last rather than, as is more conventional, first.  Partly it's because I simply found it very hard to write about, but I think it goes deeper than that: it's actually very hard to understand, partly because of the perspective issues it raises.  There's no one right answer to how to observe SRP. The official statement of the principle is “A class should have one, and only one, reason to change.”  It’s not clear to me that “one reason to change” is any better defined than “single responsibility”.  As I’ve said before, it’s...

Imagine you were writing the code modelling a car.  One you can drive, from the 1960s before they got too complex.  What does it look like? class Car { public void Accelerate(); public void Brake(); } Now, ignoring the fact that I should have started with an interface (and you can't steer), there's something very dangerous in this code.  It's the assumption that a car is an object.  It's not, it's a phenomenally complex interlinking of components.  The driver may see it as one object, but you can be assured the manufacturer does not. So what's actually...

I guarantee, you already know these patterns.  However, the patterns terminology is useful, if only to communicate the concepts quickly. Builder An object used to build another object.  The most obvious implementation of this pattern in the framework is StringBuilder.  It can be quite useful to have a builder in cases where what you're constructing is complex and you don't need to read from the constructed object as you're going.  (If you do, just using the object's own method is often simpler.)  The Builder pattern is used in fluent interfaces to support method chaining.  In this case, the builder constructs...