Sean, --- with no respect for technical skill either ---

Your approach to encapsulation is one school of thought. It confuses data hiding with encapsulation. As an architect you should know the difference. Class style accessors do not break encapsulation. Perhaps there is an argument against using with data hiding, but very weak.

I agree you are a good coding trickster. Of course, # are not required, but they are not incorrect only not necessary.

You hit the wrong point about not using CFSQLTool. It builds correct CFCs that follow encapsulation principles.

If you only want to build APIs, build libraries, don't use class objects.

this. scope variables are a very powerful feature of CFCs. The CF engine does an incredible job of managing this scope variables with class objects. Use them correctly, just as using data hiding functions correctly, means variable space is protected. Using data hiding functions is no guarantee that variables are protected.


Joseph


At 04:41 PM 10/13/2005, you wrote:
On 10/13/05, Peter J. Farrell <[EMAIL PROTECTED]> wrote:
> Joseph Flanigan wrote:
> > My recommendation is to use class style get/set instance functions for
> > data hiding requirements.
> I respectfully disagree. Points:

I disagree as well (and not so respectfully). Using "class style
get/set" accessors is a *terrible* idea and completely breaks
encapsulation since you can read *any* private data in the object and
overwrite it - heck, you can even overwrite private functions like
that!

> > value  - setContact("lastname", #form.lastname#)
> > setContactLastName(#form.lastname#)
> BTW, the #'s are not required.

Yup, sloppy programming.

> > In a CFC all instance functions are public scope whereas data
> > variables can be either public or private scope.

What do you mean "all instance functions are public"? Any function can
be public or private.

> > With CFSQLTool, the wizards generate class style get/set functions and
> > public data scope instance variables.

Sounds like a good reason not to use CFSQLTool then.

> > 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.

In other words, promote lazy programmers. Not a good reason.

> 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.

Agree Peter.

> >     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?

Like Peter I'm unable to figure out what you mean here.

> >     Variable scope. -  class functions tend to be more scopeless for
> > either public or private variables.
>
> Again, I don't see what this about.

Nor me.

> > Do not be afraid to use public variables.

Wrong! Be afraid to use public variables - be very afraid! A public
variable should be a rare exception. Using "this" scope should ring
huge, loud, clashing alarm bells in your brain!
--
Sean A Corfield -- http://corfield.org/
Team Fusebox -- http://fusebox.org/
Got Gmail? -- I have 100, yes 100, invites to give away!

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


----------------------------------------------------------
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]

-----------------------------------------------------------------------
http://www.switch-box.org/CFSQLTool/Download/

Switch_box                      MediaFirm, Inc.
www.Switch-box.org              Loveland, CO  USA



----------------------------------------------------------
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]


Reply via email to