Skip to main content
16 events
when toggle format what by license comment
Aug 27, 2012 at 3:25 comment added pdr @gbjbaanb: Yes, but why would setting italic clear the bold? Then it wouldn't be a proper decorator pattern.
Aug 26, 2012 at 22:46 comment added gbjbaanb @pdr : but look at your example, it sets bold on, then calls the underlying Textwriter (which is an ItalicWriter in this case) which sets italics on and calls the underlying TextWriter to display the text. If setting italic clears the bold flag (ie it's not a cumulative operation) then no bold text is written.
Aug 26, 2012 at 18:18 comment added pdr @gbjbaanb: Err. That's just not true. In fact it's the exact opposite of true. The entire point of the decorator is to be able to apply none, one or many and the calling code doesn't need to know at rendering time.
Aug 26, 2012 at 13:59 comment added gbjbaanb There are problems with this approach - the way you change the stream of text has to be idempotent, so you can set bold and then you can set italic and have it come out bold+italic. If, say, you change the font class each time then you will change the font to bold and then change it to italic.... you will not get bold+italic text, you'll just get the last set typeface. Decorators are ok (though a bit over-engineered for most cases) but are a pattern that is needed for certain limited cases only.
Aug 25, 2012 at 23:25 comment added pdr @BarryBrown: It doesn't imply sequence, necessarily, but you can certainly take sequence into account, where it's useful to.
Aug 25, 2012 at 22:25 comment added Barry Brown I've always thought the Decorator Pattern implies an ordering to the decorations. Consider the example code shown; how does one go about removing the ItalicDecorator? Still, I think something like Decorator is the way to go. Bold, italic, and underline are not the only three styles. There's thin, semibold, condensed, black, wide, italic-with-swash, small caps, etc. You may need a way to apply an arbitrarily large set of styles to a character.
Aug 25, 2012 at 21:14 comment added Frog I'm actually quite satisfied with the answers I received on this question, so I'm not sure whether I'll ask a new question. What different anwers can you get?
Aug 25, 2012 at 19:44 comment added pdr @Frog: Yeah, knowing that would have made a difference. If I were you, I'd raise another question and be a lot more specific about what you're trying to do. I tend to treat data objects as a slightly unique case (where getters and setters are more acceptable because I'm not trying to encapsulate logic as such) and I'll be interested to see the responses.
Aug 25, 2012 at 19:20 comment added Frog @pdr: I have taken a look at the decorator pattern, but I don't think it's what I need. I am not writing my own rendering engine, I'm merely using these classes to store the data I receive (I should have mentioned that in the question). And I don't see how this pattern would simplify my design in that case. Or am I mistaken and is there a way to implement the decorator pattern in my situation?
Aug 25, 2012 at 17:18 comment added pdr @stijn: Not really. There are a number of ways of avoiding that situation. For example, you can wrap that in a builder with a toggleStyle method (enum argument) which adds and removes decorators from an array, only decorating the final item when you call BuildDecoratedTextWriter. Or you can do as rwong suggested and complicate the base class. Depends on the circumstance and the OP wasn't specific enough about the overall spec to guess as to which is best for him. He seems smart enough to be able to figure it out once he gets the pattern though.
Aug 25, 2012 at 13:36 comment added stijn while this is a nice answer, does it not re-introduce the op's question? "bold applicaton on" -> how is this going to be done? using setters/getters like SetBold()? Which is exactly the op's question.
Aug 25, 2012 at 1:03 comment added rwong I'm a big fan of the Decorator pattern. The fact that this pattern resembles HTML (where the core operation is to enclose the input string with tags) is an attestation that this approach can satisfy all of your interface user's needs. One thing to keep in mind is that an interface that is good and easy-to-use, may have an underlying implementation that is technically complicated. For example, if you are actually implementing the text renderer yourself, you may find that TextWriter needs to talk to both BoldDecorator and ItalicDecorator (bi-directionally) to get the job done.
Aug 24, 2012 at 23:26 history edited pdr CC BY-SA 3.0
added 1 characters in body
Aug 24, 2012 at 22:11 history edited pdr CC BY-SA 3.0
added 1048 characters in body
Aug 24, 2012 at 22:11 comment added Frog Hmmm, I'm going to take a look at that tomorrow with a fresh mind and will get back to you then. Thanks for the answer.
Aug 24, 2012 at 21:54 history answered pdr CC BY-SA 3.0