my dog learned polymorphism
The moose likes OO, Patterns, UML and Refactoring and the fly likes Decorator Pattern and Java API Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Decorator Pattern and Java API" Watch "Decorator Pattern and Java API" New topic

Decorator Pattern and Java API

Rossen Stoyanchev

Joined: Oct 16, 2001
Posts: 4
I was studying the use of Decorator in the 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.
Naresh Shanmugam
Ranch Hand

Joined: Jul 16, 2010
Posts: 86
Does any body have answer to this?
Sunny Bhandari
Ranch Hand

Joined: Dec 06, 2010
Posts: 448

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

Java Experience
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

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".

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link:
subject: Decorator Pattern and Java API
It's not a secret anymore!