Decorator Pattern and Java API

[Rossen Stoyanchev]

I was studying the use of Decorator in the java.io package. According to the GoF book it's a good idea to have a "base" decorator which handles the job of delegating requests to the contained object for all methods.
I noticed that for InputStreams, the class FilterInputStream serves as a "base" decorator class, while in Readers there is no "base" decorator class. Actually FilterReader seems to be intended for that role, but then BufferedReader (which is a decorator) does not extend from it.
What is the reason for this incosistency? According to the book if there is only one decorator then there is no need for a "base" but that doesn't seem to fit the case here.
Thanks.

[Naresh Shanmugam]

Does any body have answer to this?

[Sunny Bhandari]

Yes I have.

Read the javadoc line from FilterInputStream;

The class <code>FilterInputStream</code>
* itself simply overrides all methods of
* <code>InputStream</code> with versions that
* pass all requests to the contained input
* stream

While FilterInputStream overrides all methods of InputStream, the same is not true for FilterReader and Reader.

Hope that makes sense to you about the decision of FilterReader being not the base class for other Reader's

[Tim Holloway]

I'm not sure I'd consider the IO stream processors to be decorators, to tell the truth.

However, design patterns are advisory, not concrete, and I'm not even sure if the GoF had actually written their book back when this stuff was originally designed. Much less any decision on Sun's part to go all "pattern-y".