On Thursday, Sep 11, 2003, Sean Corfield wrote:
>> I'm not going to get rid of my getter/setter methods, but mine are
>> defined
>> in my core.cfc (as get('property') and set('property', value) ), so it
>> seems>> one of Holub's arguments against them don't apply in my case: I
don't
>> have
>> added complexity because I don't have to write any code
>
>Except that having generic property accessors like that breaks
>encapsulation even more (since client code can access *any* instance
>data!).
No, not any instance data, just the preoprties defined with CFPROPERTY.
>
>> I just read Holub's article. Applied to ColdFusion MX, I think it is a
>> good
>> argument to encapsulate more of your data access within CFCs, including
>> writing methods to do display instead of retrieving values to display
>> on
>> your own. Once you put the display methods in your CFCs, then you can
>> dispense with the setter/getter methods. Holub says "Draw Thyself".
>
>You're missing a very important point in his article tho'. He says:
>
>"Bear in mind that I haven't actually put any UI code into the business
>logic. I've written the UI layer in terms of AWT (Abstract Window
>Toolkit) or Swing, which are both abstraction layers. The actual UI
>code is in the AWT/Swing implementation. That's the whole point of an
>abstraction layer—to isolate your business logic from a subsystem's
>mechanics. I can easily port to another graphical environment without
>changing the code, so the only problem is a little clutter. You can
>easily eliminate this clutter by moving all the UI code into an inner
>class (or by using the Façade design pattern)."
>
>'drawThyself()' doesn't generate HTML. To map his scenario to web
>applications and CF you'd need an HTML UI layer that applications
>called into in order to render pages - you wouldn't have HTML fragments
>in your 'drawThyself()' methods.
What else is there for it to do? Wouldn't the drawThyself method be in the
HTML UI layer?
***
The information in this email is confidential and intended solely for the individual
or entity to whom it is addressed. If you have received this email in error please
notify the sender by return e-mail, delete this email, and refrain from any disclosure
or action based on the information.
****
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
