A slightly different
angle on a very old debate. I think we all agree that getters allow for abstracting
the process of returning a value. Today getProperty just returns the value,
tomorrow it might do a transformation or calculation, so using the getter stops
that from breaking code in other objects.
They also add some
value in terms of introspection (you can see a list of methods of a class which
helps when reusing components).
Getters don't
hide data per se (only the method of creating the data) as whether you have a
reference to customer.FirstName or customer.getFirstName() in both cases you are
assuming there is a first name and if that assumption changes your calling
object will break - that's just life.
But here is a
question. Lets say you are working with queries using a gateway. You probably
don't want to instantiate a bean for every single item in a list of 200
records, but you still want to be able to display FirstName. If you add a
transformation or a calculation to getFirstName in the bean, you ALSO need to
add it somewhere in your business layer that interacts with the Gateway for
displaying queries. This seems like repeating ourselves, so I'm wondering if it
wouldn't be better to put that logic further back into the business layer which
can operate on both lists of customers (using an iterator) and on a single
customer before creating the bean (BTW do you usually put that kind of business
logic into a Gateway? where could such logic go?). But if we go that way then
the getter will NEVER do anything more than just set a value, so you could
replace the bean with a struct or a simple object with direct access to the
variables and the only thing you'd be losing was the introspection capabilities
(which don't matter to us in this case as we active generate the code
anyway).
Looking forward to
someone who's been thinking about this more than a few weeks to highlight the
blindingly obvious point I'm probably missing!
Best
Wishes,
Peter
----------------------------------------------------------Peter
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
