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...

I’ll have to hold my hands up here.  My original remarks on the composite pattern was pretty much 100% wrong.  In fairness to myself, I’m not the only one to have dismissed it as being tricky and slightly special case.  (As an aside, I really don’t think Command is a starter pattern.  To be honest, I’m still not convinced I’m doing it right.)  Like the visitor pattern, we tend to associate it with dealing with trees* and such relatively obscure topics as semantic evaluation. Actually, it’s closest to the adapter pattern.  But while the adapter pattern is about jamming...

Speaking to a colleague about the Decorator pattern, I think I was unduly harsh on decorators the last time I wrote on the subject.  I'll start off by re-iterating my opinion that writing pass-through methods is for the most part a horrible waste of time and a code smell to boot.  However, there are some cases where proxy/decorator functionality is useful where there are relatively few methods you need to proxy.  Ironically, one of these is my very first post.  It employs the decorator pattern to give you a class that executes Retlang Commands, but allows you to halt processing...