Design Patterns Explained

248 Part V • Handling Variations with Design Patterns
This creates a Headerl object trailed by a Header2 object trailed by a
Footerl object trailed by a SalesTicket object.
Decomposing by The Decorator pattern helps to decompose the problem into two
responsibilities parts:
Stream I/O
• How to implement the objects that give the new functionality
• How to organize the objects for each special case
This allows me to separate implementing the Decorators from the
object that determines how they are used. This increases cohesion
because each of the Decorators is only concerned with the func tion
it adds— not in how it is added to the chain.
Another Example: Input/Output
A common use for the Decorator pattern is in stream I/O. Let's look at
stream I/O a little before seeing how the pattern can be used here.
I will limit the discussion to input since output works in an
analogous way (if you see how it works in one direction, it should be
clear how it works in the other direction). For any particular stream
input, there is exactly one source, but there can be any number
(including zero) of actions to perform on the input stream. For
example, I can read from
• A file
• A socket and then decrypt the incoming stream
• A file and then decompress the incoming data
• A string
• A file, decompress the input, and then decrypt it
Depending upon how the data were sent (or stored) any combination
of behaviors is possible. Think of it this way: Any source can be