I posted this to the Mach-II list but there seems to be a bit more activity here so I'm cross-posting it:
In Java or other OO languages, is there a difference like this between "instance" data and "computed" data that is local to the object? I don't think there is but I could be wrong and wanted to ask. But if there is no difference, is there a compelling reason to introduce such a difference in CFCs? > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert > Sent: Tuesday, March 16, 2004 12:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] RFC, CFC Best Practices > > > I've found that using a struct in the variables scope for > instance data (I use 'my') is helpful to separate actual > instance data from computed data. Take a User business object > for example. It'll have instance data such as 'name', > 'username', 'password'. But it'll also very likely have a > validate() method which will check the values of those > fields, and store error flags somewhere for later recall by > getValidationErrors() or the like. > > Thus I'll have these fields: > > Variables.my.name > Variables.my.username > Variables.my.password > Variables.validationErrors > > Making the distinction allows to memento machinery to work > better, and also > allows generic get/set methods to be "safe". > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass > > Sent: Monday, March 15, 2004 8:38 PM > > To: [EMAIL PROTECTED] > > Subject: [CFCDev] RFC, CFC Best Practices > > > > I've noticed that many of the best practices talked about on > > this list are > > not as widely known as I would have thought. What's worse, > > most of the > > basic best practices related to CFCs are not well documented or are > > documented in disparate places. > > > > I'm trying to capture a concise list of CFC best practices > > that everyone > > coding CFCs should be aware of (if not follow). > > > > Perhaps some of y'all have comments/additions/criticisms, > > which I'd welcome: > > > > http://www.dintenfass.com/cfcbestpractices/ > > > > ---------------------------------------------------------- > > 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]
