The Decorator design pattern makes it possible to extend an abstraction's behavior without touching the implementing class at all. I didn't use to use it as often as I should in the past, but as I'm reading (for the second time, btw) the fresh edition of the excellent Dependency Injection in .NET book by Mark Seemann, I'm getting to really understand how useful it could be.
But the most amazing thing is that how elegantly Windsor Container wires up Decorators. Everything you have to do is register the Decorators in outside-in order and resolve the abstraction. For example, if we have Abstraction interface and two implementations - Impl1 and Impl2:
and we would like Impl1 be injected into Impl2 via its constructor, then all we have to do is register Impl2 as the implementation of Abstraction, then register Impl1 in the same way (no explicit names are required for both). As a result, when we resolve Abstraction from the container, we get instance of Impl2 with its _inner field initialized with an instance of Impl1. Excellent! What's more, the same trick works for collection dependencies (i.e. IEnumerable'1): a Decorator with such a constructor gets all below registered classes as a collection, which is perfectly fits into resolving composite decorators.
In the other hand, having such an automation, we can't compose Decorators in more than one way at the same time. Though, I've not met this restriction in the reality yet.