THE DECORATOR PATTERN
The Decorator pattern provides us with a way to modify the behavior
of individual objects without having to create a new derived class. Suppose
we have a program that uses eight objects, but three of them need an
additional feature. You could create a derived class for each of these objects,
and in many cases this would be a perfectly acceptable solution. However, if
each of these three objects require different modifications, this would mean
creating three derived classes. Further, if one of the classes has features of
both of the other classes, you begin to create a complexity that is both
confusing and unnecessary.
For example, suppose we wanted to draw a special border around
some of the buttons in a toolbar. If we created a new derived button class, this
means that all of the buttons in this new class would always have this same
new border, when this might not be our intent.
Instead, we create a Decorator class that decorates the buttons. Then
we derive any number of specific Decorators from the main Decorator class,
each of which performs a specific kind of decoration. In order to decorate a
button, the Decorator has to be an object derived from the visual
environment, so it can receive paint method calls and forward calls to other
useful graphic methods to the object that it is decorating. This is another case
where object containment is favored over object inheritance. The decorator is
a graphical object, but it contains the object it is decorating. It may intercept
some graphical method calls, perform some additional computation and may
pass them on to the underlying object it is decorating.
Recent Comments