To ensure you don't access the internal state of variables within an object, they are often set to be inaccessible from outside the object and are accessed instead using getter methods. For example,if you wanted to get the value of the FirstName from a User object you would call User.getFirstName().
There are two primary benefits of getter methods: encapsulation and documentation.
Getter methods promote encapsulation as if you have a property that you don't want to share, you just don't create a getter for it. So, if you don't want to provide access to the DateofBirth for a User object, you just don't create a User.getDateofBirth() method. Also, if you want to vary how a property is accessed or calculated, you don't need to change any of the calling methods – you can just change the code within the getter method.
Getter methods also provide a clearly documented interface escribing the properties that are available to call on an object so you know just by looking at the class file what properties are available for accessing.
The one downside with getter methods is that they are verbose. If you do have a lot of simple business objects with “dumb” getters that simply access the internal variable without performing any transformations or calculations (which can easily happen when building simple web applications with a databased back end), you end up with class files full of methods that aren't doing very much and it can be harder to identify the methods that contain genuine business logic, making working with the code base a slower process.
With generic getters, you simply add a single “get()” method to all of your objects and it is used to provide access to internal state. This gets rid of a lot of boilerplate code, but there are two key features that generic getters must implement to avoid losing the benefits of getters. They must be able to delegate seamlessly to custom getters, and they must limit the properties that can be accessed.
Delegating to Custom Getters
In LightBase, the get() method looks to see if a custom getter exists, so if you call get(“FirstName”), the first thing the get method does is to see whether a getFirstName() method exists. If it does, it calls that method and returns the value provided by the custom getter. In this way, you can write an application calling the generic get() method, and you don't have to change any of your calling code if you want to use custom getters – the get() method will take care of it automatically.
Limiting the Properties that can be Accessed
In LightBase, instead of creating a bunch of boilerplate getter methods to document the properties that can be accessed, you simply provide a comma delimited list of property names that should be accessible. This is a much more concise way of documenting your intent and (because it is simply stored as a variable within the object), it is also possible to programmatically change the properties that are externally available. For example, often a business object can be looked at as a state machine and depending on the state of an object, it might provide access to different properties. You could also hook in a permissions based system very easily to change the properties that are “gettable” for different users at different times.
So, generic getters are (if implemented correctly – supporting both limiting the properties that can be accessed and auto-delegating to custom getters if they exist) a powerful way to keep a code base more concise while still getting all of the benefits of encapsulation and information hiding that the “getter” pattern can provide.