Which getter method(s) are you referring to? You have to have methods that begin with 'get' and 'set' all over an app, but nearly all of them will be the 'good' kind. In other words, accessors that don't blindly set and/or return data, but rather perform some processing on instance data and return the result. For instance getUserById(id) is a 'good' method that begins with 'get'. Inside, it probably queries a database using the passed ID, and creates a User object to return. But it might call a web server to get the data, or it might hit a file cache, or do a CORBA call, etc. It's encapsulating all that, which make it a good thing to have.
You also have to have 'bad' methods that begin with 'get' and 'set' (Holub's getters and setters). These should be constrained to classes who encapsulate nothing, and only have these 'bad' methods. In other words, the objects are pure state, no behaviour. The reason these have to exist, is that you have to pass data through the application some how. The purpose of a back end (in very simple terms) is to let a presentation layer get data from the database, and the accept parameters from the presentation layer to modify the database. The issue not a black and white one. As long as you try to make every object as independant as possible, and every interaction as flexible as possible, you'll be set. The getter and setter problem is merely a common indicator that those ideals were not met. Here's an analogy. Every CF developer has had to defend ColdFusion at some point, because of the non-coders who write apps that mostly work, but give CF a bad name. Most of those apps use a page for each request, and then duplicate layout information in each. I could write an article that says duplicating layout information is bad, but sometimes you HAVE to duplicate layout information. The point of the article (and I'd write it in a less agressive tone) would be that if you are duplicating layout information, you might have a problem, so double check. At the same time, it might be perfectly valid, just watch out for traps. Morpheus: "... just like a computer system. Some rules can be bent, others broken." No mention of rules that are absolute. I always liked that quote. --- 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:47 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question > > > First you were saying how to get by without getter and setter methods > by having an abstraction layer, > Now you're saying you would make that abstraction layer work by calling > getter methods. I'm confused. > > -----Original Message----- > From: Barney Boisvert [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2003 9:34 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question > > > 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 --- 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]
