Decorator Pattern in Java IO Classes – Existence and Usage

A solution is to define a common interface that both Decorator and Decorated must implement. This interface should contain all the methods that must be decorated.

Additionally, Decorator must not be a subclass of Decorated, so that nothing is inherited from Decorated and Decorator must provide its own implementation for each method in the interface.

It is OK to have an instance of Decorated as a member variable of Decorator (strong aggregation): Decorator redirects all method calls to Decorated, as appropriate.

With a Decorator you are able to augment the code you are wrapping without changing it at all. And in some cases, not even having to know what it does.

The Open/Closed Principle states that

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

So, if you just made it abstract, what would happen if you had to then modify the description in your concrete implementation? You would have to modify your class.

Yes, this particular example is a little contrived. But, with this pattern, you can add decorators that augment a message (like in the design of Streams), or provide aspects that are orthogonal to the process (like logging or tracing) without touching or changing the code that the Decorator is wrapping.

Also, because a Decorator is a Component you can add a second Decorator without having to know that it wrapping a Decorator. In other words, this helps keep the Decorators separate from each other. This leads to code that is both decoupled and cohesive.