RE: [CFCDev] Bean and CFC question

[Jim Davis]

For a getter there are two sides:   Side A) Adding another abstraction layer is bad.  Getters are so simple why not generate them directly?   Side B) Getters are so simple!  Why would I want to clutter my component with them when a single, well defined and documented method can give me all of the same features and benefits?   For a setter the sides are similar but setters are little more complex.  In the vast majority of cases in CF setters are simple validators (since the variables are not typed the setters do this – ensure something is a number or an object or whatever).  This isn’t an issue in a typed language where the act of declaring the variable automatically brings type validation to the table.   So, to create typed setters you either need to write them manually, complicate up your generator a bit or use a generic method.  Then there are always setters that are more complex – those you’ll pretty much always have to write by hand.   In my case I went with a generic setter approach – but in a hybrid framework.  You don’t have to use the generic setters unless you want to.  Even if you want to write your own setters (and I’ll not say that my choice should inform yours) there are useful methods for that in the root CFC.  The root CFC offers type validation methods, property definition methods (you get the most “bang for the buck” with the generic setter if you define the properties in advance but you can also define them without using it and use the information in your own).   So if you like something in the DP CFC libraries you can use/extend/whatever it without being forced down the accessor path that I’ve chosen.  It’s also nice for when I invariably change my mind to agree with those that hate generic getter/setter method.  ;^)   Jim Davis   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter J. Farrell Sent: Friday, January 20, 2006 2:23 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Bean and CFC question   Nat Papovich said the following on 1/20/2006 1:10 PM: Bill's message just came in -- for the record I'm not dogging Jim.    I particularly like the accessor method description at Wikipedia (http://en.wikipedia.org/wiki/Accessor_method): An accessor method is a kind of method that is usually small, simple and provides the means for the state of an object to be accessed from other parts of a program. Although it introduces a new dependency, use of the methods are preferred to directly accessing state data because they provide an abstraction layer. The key word to me is "provide an abstraction layer"...why would added another layer of abstraction (meaning an uber get() or set() methods with custom method lookup)?  I'm no OOP guru...any thoughts?   ---------------------------------------------------------- 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