Tuesday, March 08, 2005

Getters getting me down.

Building all those getters can sure be boring. You've probably seen them about a thousand times by now. Three lines of code always looking like this:
<cffunction name="getSomeProperty" ...
<cfreturn someProperty >
At least we're getting our money out of the cut-n-paste and find-n-replace features.

The question I want to pose is:

Are we taking too big a productivity hit using private properties in cfcs instead of just exposing them with the "this" scope?

It feels like we are creating greater code encapsulation at the expense of rapid development. I've only had a few instances where I've needed a property's value to be stored in the object's instance differently than how it was to be displayed or used by other objects. These could have been handled by a few conversion functions pretty easily.

I'm also not overly fond of the gymnastics we have to go through to use cfdump. It's a really handy tool during development if you use public properties. You can see everything. Put all of your properties into the variables scope and you have some work to do.

I know we are still relatively fresh out of the gate with these things, but I'm looking forward to the day when the tools can create some of this code for us.

I think I'm getting repetative stress syndrome :(.


  1. Our organization has been moving toward a more object oriented and centralized set of components approach. We are using the this. scope in most cases, but we have found it useful at times to create a getter for variables which we know are going to change in the future, or that we need to do editing on prior to output.

    I think using the this. scope is fine as long as you can do a find and replace site-wide later on to replace them with a Getter if the need arises.

  2. Hi Chris,

    That sounds pretty cool. You retain the ability to use cfdump unaltered and you wind up with a much smaller list of functions to scan through. You only add the getters and setters where there is some processing that needs to be done.

    I guess this might get a little more interesting if the environment your working in promots sharing components between appications. I really haven't gotten that far with them yet, but I can imagine where there might be some trouble if the component developer doesn't have access to the code that's calling the component. Maybe that's a case where slavish use of getters and setters makes sense. I'm not sure.

    As an aside, I'd vote for a mod to Dreamweaver to use the post colon syntax that flash uses in the component panel. The return type in front just makes the list hard to read. At least my getters and setters tend to cluster together.

  3. There are already tools to do this!

    There is a "bean" extension for Dreamweaver that provides a wizard to create CFCs with all the getters and setters written for you. CFEclipse has a similar CFC wizard.

    Even without those you can use code snippets (in either DW or CFE) to insert getters and setters based on a few keystrokes and the name of the instance variable you want to add.

    The problem with taking the lazy way out is that when you need to change it in the future (not 'if'), then you need to change EVERY SINGLE REFERENCE to the data EVERYWHERE IN YOUR CODE. That's why encapsulation upfront is important - change is expensive!

  4. Hey Sean,

    Thanks for the heads up about the bean extension. It works really good for the short term.

    Of course, what I'm really looking for is something that will round trip between the code and the model. I'm actually working on a project that will do exactly that. It'll be nice to be able to go straight from analysis to code stubs without touching an editor. Even better if the model can be updated to reflect changes made to the code as the project progresses.

    It's always nice to see your work validated in some way. The DW extension creates code that almost looks like I wrote it.

    As far as the changes to the code, of course you're right. It was just the fatigue setting in when I made that comment.

    So, everybody, suck it up and build those getters and setters. You can't rely on global text changes to maintain your code easily. Imagine the trouble you would have if you build different objects that happen to have properties with the same name. If you decide to change one from a public property to a private property with it's corresponding accessors, you would have to actually view each change to be made. Text searches would be unable to determine which occurances to change.