ColdFusion 9 introduces implicit getters and setters with <cfproperty>. Is it possible to make private properties with an implicit get/set?
On Feb 15, 10:06 am, Dan Wilson <[email protected]> wrote: > In the case of the code you posted, I would probably not create a setter at > this this time because you have no public responsibilities for foo and the > component isn't referencing foo anywhere else but the public method > timesTen(). > > If either you chose to expose the variable foo to the public, or used a few > more internal references to foo, then I might add a setter or a getter, > whichever was appropriate, so the foo variable would have a mutation hook. > > In my world, we should keep things simple, but not too simple. Encapsulated, > but not too encapsulated. Strive for the mixture that makes sense and is > reasonably future proof. > > Should you implement the pseudo component as you wrote it, and later find a > reason to make a setter, it is an easy refactor. Leaving yourself easy > refactors for expansion is certainly much better than hard refactors, or an > overly abstract component. > > DW > > On Mon, Feb 15, 2010 at 9:59 AM, Bob Silverberg > <[email protected]>wrote: > > > > > I think this debate comes up from time to time and, for the most part, it > > comes down to personal preference. I used to use getters for everything - > > never referring directly to variables.foo or instance.foo. I think that > > there could be advantages to that extra encapsulation, as you suggest - it > > means that something other than simply "return instance.foo" could happen > > inside getFoo() and one could change that implementation without worry. > > > On the other hand, I'd venture to say that 99% of the time nothing else is > > going to happen inside getFoo(), so you haven't really bought yourself any > > benefit. It may be a case of YAGNI. Also, using getFoo() does add a > > performance hit, although negligible I'm sure. > > > Now that I've started using CF's Hibernate integration, where all > > properties are stored in variables.xxx, I've actually moved to just > > referring to the variables rather than calling the getters. A lot of that is > > out of laziness, as with CF's "implicit" getters you actually have to use > > this.getFoo(), rather than simply getFoo(), and I don't like having to add > > "this" to the call. So, to be consistent, I now tend to refer directly to > > any internal variables, rather than calling getters. > > > You raise a good point about when you have a public getFoo() method. The > > fact that it's public means that other components are making use of it and > > therefore encapsulation becomes more important. I think that consistency is > > important, so if you were to choose to use getFoo() to refer to it, I'd > > think that you should probably use getBar() as well, even if it means having > > to introduce a getBar() method (based on your example below). > > > Cheers, > > Bob > > > On Mon, Feb 15, 2010 at 9:44 AM, John Whish > > <[email protected]>wrote: > > >> Hi, > > >> Just wondering what people consider to be best practice when writing > >> CFCs in terms of getting instance data internally. > > >> For example if I have the following: > > >> <cfcomponent> > >> <cffunction name="init"> > >> <cfargument name="foo" required="false" default="1234"> > >> <cfset instance.foo = "arguments.foo> > >> </cffunction> > > >> <cffunction name="timesTen"> > >> <cfreturn instance.foo * 10> > >> </cffunction> > >> </cfcomponent> > > >> Would you create and use a private getter and setter for mutating > >> "foo"? > > >> The way I see it is that using getters and setters internally means > >> that you can add extra functionality such as type checking etc, the > >> down side is extra code. > > >> Equally, if you have a public getter for "foo", should you then use > >> the getFoo() method in your instance code? Again the downside to this > >> is that you might have a getFoo() method, but not a getBar() method, > >> so you'd end up with inconsistent code. > > >> Not a ground breaking question, just curious to know what people > >> think! > > >> Thanks, > > >> - John > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "CFCDev" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<cfcdev%[email protected]> > >> . > >> For more options, visit this group at > >>http://groups.google.com/group/cfcdev?hl=en. > > > -- > > Bob Silverberg > >www.silverwareconsulting.com > > > Hands-on ColdFusion ORM Training @ cf.Objective() 2010 > >www.ColdFusionOrmTraining.com > > > -- > > You received this message because you are subscribed to the Google Groups > > "CFCDev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<cfcdev%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/cfcdev?hl=en. > > -- > “Come to the edge, he said. They said: We are afraid. Come to the edge, he > said. They came. He pushed them and they flew.” > > Guillaume Apollinaire quotes -- You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en.
