How is the Decorator Pattern actually used in practice? [closed]

Question

I understand completely how to implement the Decorator pattern, and I also understand what it's intent is.

The Decorator is used in one of two cases:

As an alternative to subclassing - when there are multiple characteristics that an object can have, one could use inheritance in order to create subclasses for all the possible combinations. For example, three characteristics A, B and C will results in lots of classes: A, B, C, ABC, AB, AC, BC. This results in a 'class explosion'. With Decorator, one would have three decorators A, B and C, and a class D to 'decorate' - and that's it.

As a way to expand an object's functionality during runtime - we can decide which decorators to 'wrap' an object with during runtime, thus 'customizing' an object dynamically.

This was just to show that I do understand what Decorator is (I also totally understand how it's implemented). Now my question:

I'm familiar with theoretical examples of when and how to use Decorator. And as you can see I know what is it's intent. But I'm still not sure when to actually use this in practice, in an actual application. Telling me "it's used as an alternative to subclassing", or "it's used to dynamically add functionality to an object" won't be helpful since I'm familiar with it's intent.

Also telling me "think of a UI window for example. It can have a border, or not, and can be resizable, or not" isn't helpful, I'm already familiar with these theoretical examples.

So what I'm asking for is a concrete real world example of Decorator, in a practical, real-world scenario, with a brief explanation of the benefits of using a Decorator pattern there over other techniques.

---

Just to clarify, I'm not looking for a list of applications where Decorator was utilized. I'm looking for an example of where and how Decorator was used in a design, why it was a good design choice and the concrete problem that it solved. When I'll see concrete problem solved with Decorator hopefully I'll understand it better.

Answer 1

This was essentially answered by kdgregory in a comment on the question, but ...

A stream is something that can benefit from multiple attributes being added to it, independent of one another. I want a big dump of application data in a stream. Great. I also want it encrypted. Oh, in this case I also want it zipped. From this particular client, I want to change the style of line breaks they use as well.

This is an example of the alternative to subclassing your question mentions. Rather than having LineBreakFixingEncryptingZippingStream (which won't be able to inherit all 3 behaviors and so would lead to code duplication if you already have a LineBreakFixingStream, an EncryptingStream, and a ZippingStream), you can use composition of classes that share a stream interface.

So, LineBreakFixingStream decorates BoringStream, and is implemented by reading from BoringStream and forwarding the reads on to the caller of LineBreakFixingStream, except it changes the line breaks. Then EncryptingStream, which can decorate any stream, can decorate an instance of LineBreakFixingStream that, in this case, is decorating BoringStream. Then ZippingStream can decorate that EncryptingStream. Any combination of your stream classes can be put together pretty easily, even at run time if that is needed (though it isn't in my example - but you can imagine a scenario where clients call an API to put them together as one possible real world scenario that would use run time composition).

Though this is still a little abstract about the purpose, it is a real world scenario. I've composed streams before in real applications. Zipping and encrypting come up frequently, and doing a bit of custom formatting of a client data stream is common as well.