Structural Patterns - Applied Java Patterns - page 106

Depending on their behavior, some Decorator layers may be shared among multiple component objects (normally,
layers that have stateless behavior, i.e. no state is maintained or used). This can reduce memory consumption in
the system.
When taken to an extreme, the Decorator pattern usually produces a large number of layers: this means lots of
little objects between a user and the real object. This can have a number of consequences. Debugging and testing
code becomes more difficult, and the operating speed of a system can be reduced if the Decorator is improperly
designed.
You must ensure that object equality is treated properly; this is especially important for the Decorator pattern,
since object layers sit “in front” of each other. Typically, if equality testing is required in an application, you must
code an equality operation that identifies the underlying object, or the combination of the base object and the
order and “values” of each of the layers, rather than just the top layer.
Finally, it might require some work to properly handle removing layers from a system, since they could exist
anywhere within the Decorator chain. To simplify matters, some Decorators define both a forward and a
backward reference to make them easier to remove.
Pattern Variants
Pattern variants include the following:
As mentioned in “ Benefits and Drawbacks , ” it is sometimes desirable to develop Decorator classes with a forward
and a backward reference to make them easier to remove as a system runs.
Some Decorator implementations don't use an abstract Decorator . Normally, this variation is used when there is
only a single variation possible for the component.
You can create overriding Decorators , which will redefine some parts of a component's behavior. Take care
when using such a Decorator , however, since components based on this pattern can exhibit unpredictable
behavior unless there are strict rules in the code governing when and how behavior can be overridden.
Related Patterns
Related patterns include the following:
Adapter (page 142) - The Adapter pattern is intended to change the interface on the same functionality, whereas
the Decorator leaves the interface the same but changes the functionality.
Composite (page 157) - The Decorator may be viewed as a simpler version of the Composite pattern; instead of
having a collection of Components, the Decorator keeps a maximum of one reference to another Component. The
other difference is that the Decorator enhances the functionality instead of just passing on the method calls.
Strategy (page 114) - The Decorator pattern is used to modify or extend an object's external functionality, while
the Strategy pattern is used to modify an object's internal behavior.
Intercepting Filter [CJ2EEP] - The Intercepting Filter pattern uses the Decorator pattern to decorate a service
request without having to change the request.
Example
Note:
For a full working example of this code example, with additional supporting classes and/or a RunPattern class,
see “ Decorator ” on page 462 of the “ Full Code Examples ” appendix.
This example demonstrates how to use the Decorator pattern to extend the capability of the elements in a project.
The foundation of the project is the ProjectItem interface. It is implemented by any class that can be used within
a project. In this case, ProjectItem defines a single method, getTimeRequired .
Example 3.14 ProjectItem.java