Personally, I would keep the setters/getters separate as much as possible. I initially thought you could have a generice setter and getter and specify the variable name to be set or retrieved.
Then, after a bit more thinking, "what if I want to add a specific validation routine to only one variable". Maybe your idea of "grouped" setters/getters is good. What if you had separate setters, but one getter that returned a query object or a structure that contained all variables? I do something similar in that I create a component structure variable named "Instance". In my Init() method, I assign all variables as children of this structure. I can then use <cfreturn Instance.FirstName> for granular control or I can use <cfreturn Instance> to get the whole kit and kaboodle. M!ke Dawson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ousterhout Sent: Wednesday, January 07, 2004 12:06 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Best Practices Question: Getters and Setters I create some logical groups. For example, I have one getter/setter for address. Same for items on an order/invoice. Don't know if it is a best practice, just seemed to make the code more readable. I started with individual ones and everything got more complicated. Andy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 11:22 AM To: [EMAIL PROTECTED] Subject: [CFCDev] Best Practices Question: Getters and Setters I have a CFC with 26 properties. None are inherited. I find that having 52 methods for getting and setting to be a bit cumbersome to keep in my CFC with the "real" methods. I was thinking of including all my getters and setters from a CF template. Let's say that the my code looks like this: facility.cfc <cfcomponent hint="I am a facility"> <!--- Include the getters and setters ---> <cfinclude template= "facilitygetset.cfm"> <!--- Start the more complicated stuff ---> <cffunction name="firstrealmethod"> . . . </cffunction> . . . . </cfcomponent> Any thoughts on this as a good idea, bad idea, unintended consequences? ------------------------------------------------ Gerry Gurevich, Lockheed Martin [EMAIL PROTECTED] 919-572-7818 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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]
