Decorator pattern versus sub classing
An example from GoF:
Suppose you have a TextView class. Then in someplace you want a scrolled text view, so you subclass TextView and create ScrolledTextView class. And in some other place, you want a border around text view. So you subclass again and create BorderedTextView. Well, now in someplace you want border and scroll both. None of the previous two subclasses have both capabilities. So you need to create a 3rd one. When creating a ScrolledBorderedTextView you are actually duplicating the effort. You don't need this class if you have any way to compose the capability of the previous two. Well, things can go worse and these may lead to an unnecessary class explosion.
Basically, by using the decorator pattern you can add any number of additional responsibility to object at RUNTIME which you can not achieve by subclassing without potentially damaging your code structure or adding many duplicate combinations for subclasses.
But one thing, Design patterns are not something that you must use.
Whether a pattern is needed or not is dependent on your particular problem, you want to maintain the code for a long time or not, whether you want to extend or not and on many other factors like these.
And there is no pattern that is useful in all cases.
A pattern (decorator or anything else) suitable for a situation may not be a good choice for another situation.
The GoF Design Patterns book identifies two major advantages of using Decorators over subclassing:
More flexibility than static inheritance. The Decorator pattern provides a more flexible way to add responsibilities to objects than can be had with static (multiple) inheritance. With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them. In contrast, inheritance requires creating a new class for each additional responsibility (e.g., BorderedScrollableTextView, BorderedTextView). This gives rise to many classes and increases the complexity of a system. Furthermore, providing different Decorator classes for a specific Component class lets you mix and match responsibilities.
Decorators also make it easy to add a property twice. For example, to give a TextView a double border, simply attach two BorderDecorators. Inheriting from a Border class twice is error-prone at best.
Avoids feature-laden classes high up in the hierarchy. Decorator offers a pay-as-you-go approach to adding responsibilities. Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. Functionality can be composed from simple pieces. As a result, an application needn't pay for features it doesn't use. It's also easy to define new kinds of Decorators independently from the classes of objects they extend, even for unforeseen extensions. Extending a complex class tends to expose details unrelated to the responsibilities you're adding.
From my point of view, preventing subclass explosion alone is quite compelling.
If you have a TextWindow to which you want to add horizontal scrolling, vertical scrolling, and borders all independently and optionally, using subclasses, you'd have to define subclasses for HorizontalScrollingTextWindow, VerticalScrollingTextWindow, HorizontalAndVerticalScrollingTextWindow, BorderedTextWindow, HorizontalScrollingBorderedTextWindow, VerticalScrollingBorderedTextWindow, HorizontalAndVerticaScrollingBorderedTextWindow, and more if you care about the order of scrolling and bordering.
With Decorators, you only need to define two scrolling decorators and one border decorator.
Subclassing can lead to issues with the Liskov substitution principle. The decorator avoids this.
Another advantage of the decorator is that you are writing (forced to write) to an interface. This makes things easier for testing. It is true that your object hierarchy can also be written to an interface and thus have some of the same advantages, however, I can test a single implementation of a decorator class in isolation. I cannot do the same with a subclass because I will always get the whole hierarchy back to the base class. I am unable to test the new code in isolation.
Using the decorator pattern and following the single responsibility principle, I can create several decorators and stack them anyway I wish. I can configure that at runtime. In inheritance I either have to create every possible branch (a->b->c then a->c->b, thus duplicating code and exploding the number of tests), or I create 1 hierarchy then add another when needed, but this triggers a new test/release cycle.
This is why you would want to use the decorator pattern instead of subclassing.
from Decorator pattern at wikipedia
The decorator pattern can be used to make it possible to extend (decorate) the functionality of a certain object at runtime.
The whole point of decorator pattern is to dynamically add additional behaviour/functionality, which is of course not possible at design time.
from the same article:
The decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all instances of the original class; decorating can provide new behavior at runtime for individual objects.