getAddress() should probably return an Address object, even if you have a
one-to-one User-Address mapping. Assuming that, the Address object gets
created at initialization, based on some of the flat data. Implementation
looks like this:
public void init(name, ..., street, city, ...) {
myName = name;
myAddress = new Address(street, city, ...);
}
public Address getAddress() {
return myAddress;
}
public String getStreet() {
getAddress().getStreet();
}
That's a good use of getters, as long as the interface documentation clearly
indicates that getAddress will return the User's home address, and getStreet
will return the street of the User's home address, in case you later decide
that User's need to have multiple addresses. If you add multiple addresses,
then you change the getAddress() call inside the method, and the public
interface doesn't change, though the means to create a the object will be
different (no way around that).
public void init(name, ...) {
myName = name;
}
public void addAddress(key, street, city, ...) {
myAddresses[key] = new Address(street, city, ...);
}
public Address getAddress(key = "home") {
return myAddressStruct[key];
}
public String getStreet() {
getAddress("home").getStreet();
}
The change to multiple address won't affect your display code at all.
---
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 Adam Wayne Lehman
> Sent: Friday, September 12, 2003 8:54 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question
>
>
> Barney,
>
> I think we're talking about the same sort of thing. Your backend CFC (my
> core) is full of assessors right? At that layer I can only see benefits.
> S
>
> Sure you may have written getStreet() and getCity() which probably never
> get called publicly since they called within getAddress(). So what's the
> problem with it at this level? When only you display CFC will need to be
> updated if you make a chance to the getters?
>
> Adam Wayne Lehman
> Web Systems Developer
> Johns Hopkins Bloomberg School of Public Health
> Distance Education Division
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Barney Boisvert
> Sent: Friday, September 12, 2003 11: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
>
>
> > -----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]
>
> ----------------------------------------------------------
> 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]
