• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Decorator pattern within java.io

 
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know decorator pattern is used to create java.io classes. For example, Reader, FileReader, BufferedReader, which combine together showing a Decorator structure. But Let's see the code in java tutorial

Does the code above diplay how is Decorator used? I don't think so. The code below is what I think how Decorator should be used

Anyone help me to clarify that? Thanks.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So if BufferedReader adds new methods and doesn't change the existing methods, is it really a Decorator?
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
So if BufferedReader adds new methods and doesn't change the existing methods, is it really a Decorator?


According to the structure of Decorator in GOF book, I think it's not.

But... I find it's still useful to add new methods.

:roll:
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd say it's a Decorator (as it adds functionality to the read() method, the buffering) - but the readline method is not part of the pattern.

If you like, you could probably say that it's not a "pure Decorator". Personally, I don't care...
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Me, too. What's the worst thing that happens if we get the wrong answer here?
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
Me, too. What's the worst thing that happens if we get the wrong answer here?


Nothing.

I'm just learning the patterns one by one. So I want to know exactly what it is. Am I going in a wrong way?

Thanks.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Louis Wang:
Am I going in a wrong way?



Design Patterns aren't cookie cutters or Simplicity (sewing) patterns. There is no need for a 100% match of all features. Given a problem of a particular type it represents the essence of a recurring solution that balances often competing forces of design principles.

Given that the motivation and the "balance" for any concrete problem is going to be somewhat different from the ones stated in the pattern description it must be expected that every application of a pattern is going to emphasize some aspects over others, sometimes to the point that some non-essential (but often useful) aspects may be ignored. When you apply patterns you are not just working in black and white, you are very much working in continuum of grays, using what you need for your particular problem (which sometimes means not using patterns at all).

Ultimately mastery of the Object-Oriented design priciples is more important than rote learning of a litany of design patterns. Familiarity with these design principles will tremendously aid in the understanding of design patterns as each of them typically use a number of these principles to arrive at their essential solution. These design principles also guide you when you adapt design patterns to your concrete problems.

Also don't lose sight of the fact that design patterns greatest contribution is probably in the area of design communication (written or oral).


What Larry Wall said about Perl holds true: "When you say something in a small language, it comes out big. When say something in a big language, it comes out small". The same is true for English. The reason that biologist Ernst Haeckel could say "Ontogeny recapitulates phylogeny" in only three words was that he had these powerful words with highly specific meanings at his disposal. We allow inner complexity of language because it enables us to shift that complexity away from the individual utterance.


p. xlv, The Ruby Way, 2e (amazon US) by Hal Fulton

In other words design patterns let us express "big ideas" simply.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Although I agree with everything Peer said, to truly understand the gist of a pattern, it certainly seems to make sense to also look at it from black vs. white point of view. So, no, I don't think that you are going the wrong way.

As an aside, http://industriallogic.com/papers/learning.html might be interesting to you.
 
reply
    Bookmark Topic Watch Topic
  • New Topic