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
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...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 29, 2003
Me, too. What's the worst thing that happens if we get the wrong answer here?
Joined: Jan 28, 2005
Originally posted by Stan James: Me, too. What's the worst thing that happens if we get the wrong answer here?
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?
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.
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.