Joseph Flanigan wrote:
My recommendation is to use class style get/set instance functions for
data hiding requirements.
I respectfully disagree. Points:
1. "Class" style accessors are too generic unless the object is a
generic object such as a generic transfer object.
Having a defined set of accessors allows you to formalize your API.
Having a consist API is important especially when working a team
environment. This also allows your code to document itself instead of a
developer documenting it. If you have a getLastName() accessor, then
any developer on the team should be able to figure out that
getLastName() holds a person's last name. Generic accessors can unlock
holes that make it "easier" to write code that could be difficult to
debug and harder to maintain legacy code.
If I continue with my get/setLastName() example, take the following code.
Defined Accessor (or "data" style as you defined):
<cfset someObj.setLastNaem(variables.someVar) />
ColdFusion will throw an error saying that setLastNaem() method does not
exists. It's easy to figure out what I did wrong.
Generic Accessor (or "class" style as you defined):
<cfset someObj.setContact("lastNaem", variables.someVar) />
ColdFusion will happily place the variables.someVar into a misnamed
lastNaem instance variable inside your CFC. Now, when I try do
something - I need to figure out where my lastName went.
2. Lack of Data Type Checking, Access Types and Default Values
Although a lot of accessors are used for setting form data (which means
the type="string"), however some don't except form data. I want to make
sure that my setFieldArray() really only takes an array and not
something else.
When using generic accessors, you lose the ability to control how the
accessors are accessed. For instance, you may only want to be able set
a piece of instance data during the init() only - making the setter's
access type private and the getter public.
You also lose default values that can be set in the cfargument.
3. Writing defined accessors are easy if you use a code generation tool.
I usually don't plug tools unless they are free, but Rooibos Generator
(http://rooibos.maestropublishing.com) can generate a beans or accessors
by template code. Beans follow are a relatively strict format and
accessors are low-level code which means they are really mundane to
write. Use a code generator - generic accessors are usually, IMHO,
just plain lazy.
Explanation.
Encapsulation means data and functions about an object are defined
together as a class. Data hiding is a programming technique that is an
indirect access to a class's data. Data hiding is usually implemented
by extending class functions with function names like getter and setter.
Two styles of getter and setter functions are often used.
class - the class name as the function and variable name passed with
value - setContact("lastname", #form.lastname#)
data - variable name with value passed as value.
setContactLastName(#form.lastname#)
BTW, the #'s are not required.
Either style allows data hiding.
In a CFC all instance functions are public scope whereas data
variables can be either public or private scope. Data hiding functions
can be used with either scope. Some proponents say data hiding with
private variables should only be used. I think this limits the
benefits of class structures.
What are the limitation? More information would be appreciated. If you
put your instance data in the "this" scope, why bother writing
accessors? I might as well just say:
someObjec.lastName = variables.someVar
If you are going to going through the trouble, make your instance data
"private" by using the variables scope.
With CFSQLTool, the wizards generate class style get/set functions and
public data scope instance variables.
There are 3 reasons for using class functions style.
Less code. Unless the setter is doing data verification, there is
no need for separate functions for each instance variable.\
But way, way less control...no data checking, no method access control,
no special logic for specific setters, no default values and the
potential for undocumented or poorly documented API, etc. Again, having
a well specified API when working in a Team is a must.
Namespace management - mullti-level hierarchies allow lower levels
to access higher level values. e.g. contact.employee.staff
getContact() works in all levels but only instance in contact.
What is this benefit about?
Variable scope. - class functions tend to be more scopeless for
either public or private variables.
Again, I don't see what this about.
Further.
Do not be afraid to use public variables. You may not need data hiding
get/set functions. cfcContact.lastname = form.lastname is an
encapsulated structure. cfcContact.setContact("lastname",
#form.lastname#) is encapsulation using data hiding.
I've never really heard of any good reason to use the "this" scope
except for two reasons:
1. <cfreturn this />
2. If you are trying to make a glorified struct such as an LTO and this
reason is shaky at best sometimes. The only good reason to use this
over a plain old struct is documentation - your cfarguments document
what is supposed to held in the LTO as well as there data types and
possible default values. An LTO object can be read by the cfcexplorer -
providing documentation on this "glorified" struct.
Best,
.Peter
--
Peter J. Farrell :: Maestro Publishing
http://blog.maestropublishing.com
Rooibos Generator - Version 2.1
Create boilerplate beans and transfer objects for ColdFusion for free!
http://rooibos.maestropublishing.com/
Member Team Mach-II - It's coming...we're in a code freeze!
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
