4 ms·

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,

by pbourke 16y ago

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 a problem when people assume that getters and setters must always occur in pairs. They shouldn't! Getters can expose whatever is needed to communicate the object's external identity and state. Setters are mostly a code smell. You should pass whatever you need to a constructor and use behavioural methods to mutate the internal state after construction. For instance, a Car class can have a getSpeed(), but shouldn't (in a clean design) have a setSpeed(). It should have stepOnTheGas() or increaseSpeed(). Getters and setters make classes into little more than verbose structs. Obviously everything I've said is aimed mainly at Java-ish languages, which was the focus of the OP's comment.

gwtw 16y ago
Getters and Setters are only semantically correct for Java Beans. In pure usage of the language, clearly if a class with an immutable public element is appropriate, you may use it. If you only need a getter for your immutable property (and are not writing classes that are destined by management by a container) then do so. It is perfectly OK. However, if your Java object is ever going to be treated generically by a tool, container, external system (serialization), etc., then you need to "expose" your internal structure. After all, the user of the object may in fact be tasked with "initializing" the object. (In other words, imagine you are the author of a visual editor for Java programs.) Before criticizing the good engineers at Sun, remember that annotations were not available back in the early days. Today it is in fact quite possible to design a new specification for Java Beans that delegates ALL code generations to annotation processors and gives you the developer a set of annotations to sprinkle on your otherwise uncluttered Java code.
jerf 16y ago
"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.

by pbourke 16y ago

gwtw 16y ago

Getters and Setters are only semantically correct for Java Beans. In pure usage of the language, clearly if a class with an immutable public element is appropriate, you may use it. If you only need a getter for your immutable property (and are not writing classes that are destined by management by a container) then do so. It is perfectly OK. However, if your Java object is ever going to be treated generically by a tool, container, external system (serialization), etc., then you need to "expose" your internal structure. After all, the user of the object may in fact be tasked with "initializing" the object. (In other words, imagine you are the author of a visual editor for Java programs.) Before criticizing the good engineers at Sun, remember that annotations were not available back in the early days. Today it is in fact quite possible to design a new specification for Java Beans that delegates ALL code generations to annotation processors and gives you the developer a set of annotations to sprinkle on your otherwise uncluttered Java code.

jerf 16y ago

"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.