Decorator
There are 5 entries for the tag Decorator

You’ve probably never heard of Yadic.  It’s the smallest DI container I’ve seen.  I’ve linked directly to the only source file because it’s a good read, even if Google Code can’t do syntax colouring for F#.  It’s more opinionated than a party political conference and has some neat ideas.  One of them is the concept that you can specify that a service be decorated. Let’s just run through that again: you can take a service and stick a decorator on it.  Now, you may be thinking that you can already do this in most containers, and you can but it’s slightly...

With all of the substitution patterns, the principle is that the proxied target doesn't need to be aware of the proxying object.  That's pretty achievable if what you're trying to do is provide a local proxy to a remote object.  However, when you're using a decorator, things get a bit trickier.  Welcome to the "leaking this" problem. To start with an easy example, what if the target does this: return this; What do you do?  Well, it's not obvious, but typically you'll get the decorator to return itself.  This case...

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

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

Some patterns are so good they become part of the way that people think about systems.  They get implemented using general solutions and then people just use them as a piece of technology.  In these cases, a modern developer is himself unlike to implement the pattern, he's much more likely to just use the libraries that implement the pattern.  I'm terming these infrastructure patterns. Proxy and Decorator A modern developer lives with proxy objects the whole time.  If you have an object X, a proxy for object X behaves is an object that exposes the same interface...