in reply to OO Getters/Setters
First off sorry if this seems like a rant, but I've been up all night.
This is a lesson most programmers who are new to OO should learn right up front: there are objects and then there are data structures. Objects store state. Data structures store data. Why is this important? Because you sometimes end up with a really goofy interface to objects when someone decides, "hey, let's make everything in our blessed hash accessible through getter and setter methods." Interaction with an object should affect its state. Granted there will be methods to alter the data that the object is working upon. However, these methods will usually do a few things such as check current state, alter other values, and possibly even reject certain changes it deems as invalid. If you are going to just use something that automatically generates these getters and setters, why even bother? It's a blessed data structure. Let them just use the access methods provided by the data structure. Some may argue with me on this point because there's oogity boogity stuff about allowing someone to reach into the object and change it directly. But aren't you already doing that by offering these getter/setting methods? Certainly at some point in the future you may decide to change the underlying structure and decide to still provide the old methods for backwards compatibility. My response to this is that you ought to plan out your object. Your interface shouldn't reflect the underlying object data structure. Your underlying data structure, however, should support the object.
|
---|