Yes, using getName() is preferable to using the property "name" -- in fact, if you want to be formal about it, you shouldn't even have a publicly accessible property called "name" (and you avoid that by NOT using "this" for your instance data -- instead use the unnamed scope [some use a "virtual" scope, as discussed in previous posts]).
[I'm cheating here by excerpting from a previous post of my own...] In general, I think the compelling reason to not put data members in a public scope is that it does not allow the separation of implementation from interface. Such separation is good for two reasons (among others): 1) It allows me to change how my CFC works internally, without messing up any code that uses it. As a quick example, let's say that inside my CFC I have an array of structures called bunchOfStuff that stores some interesting information. I then have methods getFoo(key) and getNext(). If bunchOfStuff is a public data member the developer using my CFC may be tempted to just manipulate it themselves. But, what if change it be a struct of structs to allow some extended functionality? Or change it so that it's an array of other component instance? Now the developer who used the private data member is going to get burnt. 2) It prevents the developer using the CFC from getting themselves in deep trouble. If bunchOfStuff is public in the above example, the developer could start manipulating it themselves, thus taking control away from the CFC to manage data integrity/validation/etc. Let's say each struct in the array called bunchOfStuff must have a very specific makeup -- by creating methods to manipulate it I can make the CFC do any validation to ensure everything is OK -- I get to make assumptions and deal with the implications of those assumptions. If bunchOfStuff is suddenly available to the developer using the CFC, the ability of the CFC to understand it's own assumptions is shot, and very strange badness that would be very hard to debug could result. I also think that having data in the public scope breaks the object paradigm that CFC's naturally stem from. Yes, they are not a true OO language, but so what? It would still be great if the CF community could learn some of the lessons from the OO community now that we have an object interface. I'm less anal about the issues of "breaking the paradigm" than some, but I can certainly see the merit of the argument that the nature of a component is to expose its functionality via methods, and providing access to internal data without methods breaks the model and creates potentially very disparate looking code in CF-land, which could be bad. - Nathan > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sparrow-Hood, Walter > Sent: Wednesday, July 30, 2003 11:53 AM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Accessing CFC properties (data) > > > First of all I'd like to thank the regular contributors to this > list. I've > been monitoring the discussions for the last month or two and it has been > extremely useful for someone like me who is struggling to use > CFCs correctly > but who doesn't have a background in Java or OOP (I cut my teeth > many years > ago on FORTRAN!). > > Now for my question, which, I guess, is really one of encapsulation: > > I understand that you should never set an objects properties from > outside of > the object as in: > session.objUser.name = Joe > > But what about retrieving the objects properties? Is > > name = session.objUser.getName() > > preferable to: > > name = session.objUser.name > > and why? > > > Walt ---------------------------------------------------------- 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).
