Yep. And the example of display is a horrible one. Every time you want to add a new output device, you still need to add new renderers and you gain no actual benefit IMO. Not to mention a horrible lot of UI inconsistency.
Besides, having an object provide so many functions is horrible in terms of tying to keep objects cohesive and encapsulated. If every object were to try to anticipate every action that it was going to be told to do, they'd all grow to be huge, functionally (un, non?) in-cohesive beasts. You'd now have your objects performing multiple unrelated tasks, which is just plain bad in almost every situation. RenderThyself is just another example of a limited-use pattern that people have tried to over-apply. In fact, the _only_ widespread use of it that I have ever seen is in UI control libraries (X, WinForms, GTK, AWT, etc) and they render the controls to one or two known mediums that comprise a very finite set of possible targets. For the record, the article is _extremely_ java biased, and Holub's argument that it's "<not really putting> any UI code into the business logic" is pure bunk - he's delusional on that point. FYI, the replies to the article itself have _tons_ more well thought-out responses than I could even begin to find the time to write ;) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RADEMAKERS Tanguy Sent: Tuesday, February 28, 2006 12:20 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Where use getters (not setters - different discussion)? >What happens when the target that the object is rendering to >changes? Should we provide a renderMeToPrinter(), renderMeToScreen(), >and renderThyHeadUpThyAss() call for every property on every object? >What if the object is for public consumption and you have absolutely >no control over the output devices? Just a plain bad idea in my opinion. As explained in the article, you go for strategy b) there (return an object capable of rendering the information you want rather than a straight out string) and adapt the facade pattern to make sure you get the right "kind" of object depending on where you want to render (so in this case, an instance of screenRenderer, printRenderer, or headUpTheAssRenderer, as needed). This is all pretty much blue sky stuff for CF developers (although, maybe with more and more flash interfaces, who knows?) since we don't have widely adopted display side OO techniques at our disposal, whereas the java guys have swing and awt and so forth, and that's kind of hiding the point the author is trying to make. Display is just a red herring: the author's point is that it is better to "tell" an object to doSomethingWithX() rather than "asking" it to giveMeTheValueOfX() and then doing something with that yourself - especially if X is "just" a primitive instance variable. /t ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
