Snippets: A Generic Getter

I love dynamic programming patterns. All other things being equal, the less code in your application, the eaiser it is to code, debug and maintain. Thoughtfully applied dynamic programming can drastically cut the amount of code in your application, making it much more maintainable and flexible. Imagine having a single generic base getter for all of your objects that would support information hiding, remove the need to test for existance, and that would seamlessly support overloading by custom getters where required. That's what I'm playing with here and it seems (so far) to be working very well . . .

Lets start by looking at the design decisions, and then I'll share the (fairly trivial) code.

Firstly, I wanted to make sure that my generic getter wouldn't just share all of the properties loaded into my iterating business objects, so I added a private variables.gettableAttributeList() property to my base bean with a comma delimited list of the attributes I wanted to share. It does support a * to share all of the internal properties, but that is more for quick prototyping than for an actual system and I'll probably remove that feature as I start generating the business objects again. If an attribute name isn't on that list for the particular object called, the generic getter won't even try to return it.

Secondly I didn't want to get ColdFusion errors just because someone called for an attribute that didn't exist. I'm not sure how to handle this for the long term, but right now the method can either return a null string or an informative error message if you get an attribute that doesn't exist. The null string is very useful for the Input facade I use to wrap form and URL variables as I can always just call Input.get('whatever') and just test for length. Of course, it removes the small amount of information that distinguished between a variable not existing in the scope and it having a null length, but that is a price I'm willing to pay to avoid all of the If IsDefined("input.whatever") code I used to have to write.

Thirdly, I wanted to support custom getters that would automatically overload the base method but only for certain attributes. If there was a custom getter for User.get('Age'), I wanted to use that, but if there wasn't one for User.get('FirstName') I wanted to just use the generic method.

Fourthly I wanted to make sure that only my bean needed to know whether or not there was a custom getter for a given property. If I have to call User.getAge() (for the custom method) and User.get('FirstName') (for the generic one) I'm exposing more details of my beans internals than I really should.

So, how does it work? Have a look at the code and I think you'll see it is pretty obvious . . .

Firstly it checks to see if it is allowed to get the attribute or not (thus removing the biggest issue I usually have with generic getters that just let ALL of their properties hang out!). If so, it looks to see if there is a custom get#AttributeName#() method. If so, it calls that and returns that value. If not, it uses a special "hardget()" function. This is responsible for pulling the value of a given property from the array of structures it is stored in for the current iterator record. It encapsulates knowledge of the actual data structure within the variables scope and is often used by the custom getters (I'll show one of those in the next post) which need to actually get property values and then operate on them to return a particular attribute (e.g. hard getting a Date of Birth to return a users calculated Age).

You also see that if the attribute isn't gettable or the method (or its sub method) fails, it either returns a null value or a meaningful string. I'm not happy with how this works, but as I'm not sure what problems I'll need to solve, I'll just leave this alone until it becomes a problem and will refactor it from there.

I have found this a boon in prototyping applications, but even in a live app, it removes the need for "dumb" getters, supports information hiding and still allows for seamless addition of custom getters where business rules become necessary. I certainly couldn't have finished my last two projects in the timeframe I did without this and the iterating business object I've been talking about for the last couple of weeks.