>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
