a definitions section is an idea, but this is an article not documentation. I'd rather not elaborate as my purpose is not to discuss the writing; bottom line my question is this:
I personally am not really sure what a decorator does, though I know it's a design pattern. Ayup, I can look it up. But I am saying that the average reader should not need a dictionary or a reference text to read the article. So am I a typical reader in this regard? I mean, I know I have less CF than you most likely; I am not sure much OO or design pattern knowledge a group not unlike this one might have. Make sense? On 2/5/07, Cameron Childress <[EMAIL PROTECTED]> wrote: > Well, my own personal belief is that Design Patterns shouldn't > typically require documentation. Part of the point of Patterns is to > use a common language for describing common code problems and > solutions. Usually the only reason I would ever describe a pattern in > code docs would be to make any distinctions about specifically how I > implemented a pattern - not in one specific case, but in general how > that pattern is expressed in the code. > > In your case, if there is a need to explain the Decorator Pattern and > who it's used in the app, it might be good to pull it out into a > definitions section of the docs. I'm a little perplexed about the > root subject of the doc snippet you posted since it does seem to > describe some workaround that applies inheritance in some un-natural > way. I'm sure it's all out of context though, so who knows. > > -Cameron > > On 2/5/07, Dana <[EMAIL PROTECTED]> wrote: > > hehe. Ya well, overly wordy it is, and yes, it does look a lot like > > inheritance, good point. Which your average developer does not need to > > have explained, correct? SO that is one issue -- how is this different > > than inheritance, and if not all all, why are we explaining it. The > > other is this decorator mentioned in passing, which is not explained, > > and I am thinking should be? I should probably mention that I am > > trying to elicit a rewording from someone, not just trying to read it, > > and that is why I am asking these questions > > > > On 2/5/07, Cameron Childress <[EMAIL PROTECTED]> wrote: > > > That sounds like a overly wordy description of inheritance. > > > > > > -Cameron > > > > > > On 2/4/07, Dana <[EMAIL PROTECTED]> wrote: > > > > ok so...suppose I say > > > > > > > > ' ...provides functionality for the specified decorator to also > > > > automatically extend all the public methods of the generated Object. > > > > This means that within the CFC designated to be the decorator, it has > > > > access to all the methods that are generated, but also has the ability > > > > to overload those methods, and overwrite or extend the default > > > > functionality." > > > > > > > > this requires no further clarification? I find this slightly rough > > > > going, but I am entertaining the possibility that this is cause I'm > > > > me... > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 Experience Flex 2 & MX7 integration & create powerful cross-platform RIAs http:http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Community/message.cfm/messageid:226910 Subscription: http://www.houseoffusion.com/groups/CF-Community/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.5
