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.
