Generic Getters and Setters

The generic getter (get(AttributeName)) has got a bum rap. Many people use it to shamelessly expose the internal workings of their business object, removing most of the benefits of information hiding/encapsulation that an object should provide. But imagine a different world . . .

Imagine if you had a list of values within your object but you had a separate getGettableAttributes() method that returned a list of “gettable” attributes and another getSettableAttributes() method that returned a list of settable attributes (bearing in mind you can wrap these and the generic getter and setter using AOP to implement personalized attribute level security).

Now imagine that when you get(AttributeName) it just checks against the above list. If you are allowed to get that attribute, it looks to see if it has a specific getter. If so, it calls that and returns the value. If not, it just takes the internal attribute value directly and passes it to you. Ditto for setters.

Firstly this frees us from writing standard getters and setters for attributes that don’t require a calculation (I don’t care if the computer writes them – if they are there in the code base and you ever touch the code, they make it less readable). Secondly this preserves information hiding – if you don’t explicitly add an attribute to the gettable and/or settable list, nobody can access/mutate it (so you can protect date of birth and just share Age as a calculated getter – solving the biggest complaint I used to have with generic getters and setters when I first saw them in the wild). Thirdly, you get complete control of error handling without a bunch of error trapping code. If the attribute requested isn’t in the list, you can return a simple message, or do some kind of logging or notification. Finally it is extremely easy to write generic object.get(variable) loops for displaying dynamic attribute lists rather than having to use the object[“get” & variable]() syntax which I find a little less readable.

Of course, you are forced to replace method introspection with a simple call to a manually maintained list of attributes, but I’d much rather type a couple of lists of attributes than create and maintain 20 behaviorless getters and setters on each of my business objects. It also simplifies the code by removing any introspection routines, and because I generate my attribute lists, I don’t really even have to worry about my attributes, properties and calculations getting out of synch as they’re all generated using the same metabase.