Design Patterns Explained

25O Part V • Handling Variations with Design Patterns
Instantiating the
chains
2. Read, decompress, and decrypt the data— all transparently to
the client object that is using it. The client merely knows it has
some sort of input stream object.
If this client needs to get its input from a different source, the chain is
created by instantiating a different source object using the same
behavior objects.
Understanding "The Complete Stream Zoo."*
Java is notorious for a confusing array of stream inputs and associated
classes. It is much easier to understand these classes in the
context of the Decorator pattern. The classes directly derived
from java.io.InputStream (ByteArrayInputStream,
FileInputStream, FilterInputStream, InputStream,
ObjectInputStream, SequenceInputStream, and
String-BufferInputstream) all play the role of the decorated
object. All of the decorators derive from the
FilterlnputStream (either directly or indirectly).
Keeping the Decorator pattern in mind explains why the Java
language requires chaining these objects together when they are
instantiated— this gives programmers the ability to pick any
number of combinations from the different behaviors available.
Horstmann, C., Core Java— Volume 1— Fundamentals, Palo Alto, CA: Pearson
Education, 1999, p. 627.
Field Notes: Using the Decorator Pattern
The power of the Decorator pattern requires that the instantiation
of the chains of objects be completely decoupled from the Client
objects that use it. This is most typically accomplished through the
use of factory objects that instantiate the chains based upon some
configuration information.