Kind of. ; ) I'd have the original CFC create a very lightweight object containing the data (only instance data, a constructor, and a getter for each instance variable) and pass that from the original CFC to the one doing the display. In effect, the display CFC would call the backend CFC and get all the data in one fell swoop.
I usually have a set of lightweight business objects (User, for instance) that are pretty much glorified structures with a full set of 'bad' getters and setters. They also have some 'good' getters, such as getAge (using the dateOfBirth instance variable). Views are normal .CFM pages (I'm using Mach-II for most of this, and Fusebox 4 for the rest), and then there is a UserService which creates and persists all User objects, as well as performs other User related tasks. So during a request that displays user information, the flow looks something like this: get request security, etc request.user = UserService.getUserById(#attributes.id#) include dsp_userinfo.cfm do page-level layouts the dsp_userinfo.cfm file (which is analogous to your CFC) only knows how to get info from the User class, it doesn't know how to get one. With that separation I can replace the UserService object with a totally different object with a totally different interface, and my display code needn't change, because it's still only going to interface with the User object. barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Brad Howerter > Sent: Friday, September 12, 2003 8:06 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question > > > Thanks, Barney. Here's what I don't get: > If we have to have an abstraction layer CFC produce our HTML, isn't > that CFC going to have to call a lot of getter methods on > the original CFC? > > -----Original Message----- > From: Barney Boisvert [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2003 8:58 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question > > > Objects aren't designed to hold data (though they nearly always do), they > are designed to hold data and manipulate it at the direction of other > objects (via message passing). If this is the case, then in general, only > the actual object needs to know what the data is, and so getters > and setters > bound to instance variables are unnecessary. There will always need to be > methods whose names start with 'get' or 'set', but as long as they do > something besides blindly return instance data (compute an age from a DOB, > combine first and last into a full name, etc), they aren't 'getters' or > 'setters' in this sense. Holub said in the article that if you have to > change a method signature if you change the instance data (getAge and > getFullName can stay the same), it's a bad method. > > If you build classes like this, they'll be very cohesive, and able to be > coupled together very loosely. The side effect, of course, is > being unable > to do much of value on their own. Therefore you HAVE to have a collection > of different classes working together in order to get any meaningful job > done. That means lots of abstraction layers, but it also means that any > given object can be completely shredded internally and it won't affect the > system, as long as the object's public interface is left intact. > With that > in place, maintenance of a system becomes a breeze, because you can be > ASSURED that changing an object's implementation simply cannot affect the > rest of the system. You can also pull an entire abstraction layer out and > replace it seamlessly, as long as the layer as a whole has the same public > interface. > > cheers, > barneyb > > --- > Barney Boisvert, Senior Development Engineer > AudienceCentral > [EMAIL PROTECTED] > voice : 360.756.8080 x12 > fax : 360.647.5351 > > www.audiencecentral.com > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Brad Howerter > > Sent: Friday, September 12, 2003 7:33 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question > > > > > > I disagree that that was his point, but you're close. His point > > is that we should rarely create getter/setter methods. He doesn't > > care whether you've automatically created them. > > > > But I don't agree with Holub. I think > > the overuse of them is the problem, not their creation. And one way > > to avoid their overuse is to have the objects display themselves. > > > > But Holub and Corfield say we should put methods that > > do that in a different layer. Why? > > > > -----Original Message----- > > From: Hal Helms [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 12, 2003 1:31 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question > > > > > > Holub's point is that the *automatic* creation of *public* getters and > > setters is a problem. It's not that they're somehow evil; it's that we > > should make sure that we can't let the object do whatever work we might > > be wanting the info for. It's a good point, but it's all too easily > > warped into "Don't use getters and setters." > > > > Hal Helms > > See halhelms.com for classes in... > > Java for ColdFusion Programmers > > Fusebox 4 > > Mach-II > > OO Applications with CFCs > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Nathan Dintenfass > > Sent: Thursday, September 11, 2003 5:18 PM > > To: [EMAIL PROTECTED] > > Subject: [CFCDev] Getters and Setters WAS: DB and OO question > > > > > > I got that same thing from the article, but that goes against everything > > the OO folks in CF-land (Sean, foremost among them) has been preaching. > > So, frankly, I'm confused as to what is being suggested here. > > > > Is the rule being espoused that getter and setter methods are only for > > "public" methods that an end-developer will use? I could understand > > that, but that's not what I'm reading on these posts and in Sean's blog. > > > > If I've got a Person and a PersonPersister (to use someone else's > > example), and I say something like: > > > > personPersisterInstance.savePerson(personInstance) > > > > Should the PersonPerister not call the getFirstName(), getLastName(), > > etc. methods from Person, much the way I would have the the PersonRender > > custom tag might do? > > > > I just KNOW that Sean isn't proposing public data members > > (personInstance.firstName), is he? ;) > > > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Behalf Of Brad Howerter > > > Sent: Thursday, September 11, 2003 1:44 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [CFCDev] DB and OO question > > > > > > > > > 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 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] > > > > > > ---------------------------------------------------------- > > 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] > > > > > > *** > > 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] > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003 > > ---------------------------------------------------------- > 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] > > > *** > 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] > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003 ---------------------------------------------------------- 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]
