This isnt a perfect OO implementation because it is completely untyped, but I have essentially generic beans that only have 3 functions:
init - accepts a list of field names, and uses them to create a struct in the variables scope setValues - accepts a struct or query, and looks for the fields defined in init, setting the appropriate struct keys where found getValues - returns a duplicate of the struct I have done this because a lot of my beans have 10+ fields, and frankly, calling 10 sets and 10 gets seems a hideous waste of resources to me, both my time and the processors. So, its not perfect, but it does make it impossible to set or access the values directly, and it gets the job done much quicker - (write once, use everywhere), which equals rent paid, gas in the tank, food on the table. Anyone care to comment on / rubbish this method? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sean Corfield Sent: 13 October 2005 23:42 To: [email protected] Subject: Re: [CFCDev] Inside the CFC: use Getter/Setter or Instance Scope 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] ---------------------------------------------------------- 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]
