|
"You almost always need to have a client object observe the state of an instance - clients need to marshall it for the network or log some information about it, etc. So getters make sense." It's always a challenge to figure out when to cut off my discussion since I could go on for quite a while :) But definitely there's some cases for them. Another example where they do make some sense is when it really is a verbose struct. A "Point", 2D, 3D, or otherwise, is generally a struct. You may have some basic methods on it, but you're going to be examining the internals of it an awful lot for anything nontrivial. (And I've fiddled with some serious OO design patterns, like layering transforms on the Point objects themselves, and the problem is that performance has always been terrible then.) You know you have one of these cases on your hands when you realize that you don't even need the getter/setter, you might just as well expose the internals, because the internals are what the object is. (Like most, I was educated into OO dogma, and one of the earlier clues that something was wrong with it were these sorts of things that simply weren't objects and shouldn't be. A Point is just a Point, and trying to abstract the point usually isn't worth it. You very well may want to layer abstractions on top of that that provide further guarantees, and I usually stick some methods on the Points for syntactic convenience, but the Point is not itself a very good object.) Also, if you're marshalling, you do need some sort of symmetry for getting and setting, though I prefer the getSomethingMarshable() and setWithSomethingMarshalled() (or constructWith...() ) blob approach you often see in the dynamic languages. |