Re: use of setter and getter methods
JT wrote:
Jonie wrote:
Hi,
Following is a code snippet that teaches java coding conventions.
Around the bottom of the snippet, I notice setter and getter methods.
I don't know why I am advised to write setter and getter method. Could
anyone explain what the use of setter and getter methods are.
Encapsulation. One of the primary rules of OOP is encapsulation, the
act of protecting your class variables from being accessed directly. We
use getters and setters so that if a change to the value of an instance
variable is required, the changing class or method has to call the
setter. Same goes for getters.
This business of encapsulation is not just a matter of
religion, but offers practical advantages. Consider writing
a class without getters and setters: How would users of the
class observe and influence the stored values? You'd need
to make them public (or maybe protected or package-private)
so the users could access them, and then the users would
simply write `x = thing.value' or `thing.value = 42'.
This creates a bit of a problem. Suppose you're debugging
a program, and you've discovered that the bad behavior occurs
because somebody sets thing.value to a negative number even
though that makes no sense. How are you going to find out who
did the dirty deed? With everybody and his brother-in-law
executing `thing.value = somePlausibleCalculation()', the job
of tracing the fault further back towards its origin is hard.
If instead you make the value private and use a setter, the
job becomes far simpler:
private int value;
public void setValue(int value) {
assert value >= 0;
this.value = value;
}
This way, the culprit is caught red-handed, in the very act
of trying to stash the bad value. You have moved beyond the
damaged thing, one step closer to the source of the damage.
If it sounds too pessimistic to fret about debugging, think
of a different scenario: Your object holds several values of
various kinds, some of which are derived from computations on
the others. You want to be sure that thing.x and thing.y are
in agreement with thing.rho and thing.theta, to take a simple
example. You *could* just expose all four variables and write
JavaDoc to warn the users not to let them get out of step --
but if you made the variables private and wrote setters you
could enforce the agreement for yourself instead of saddling
your users with the burden (and with the opportunity to blunder).
Going still further, consider that getters can do more than
just copy out stored values. In the Cartesian-and-polar example,
you might discover that almost everyone uses the x and y values
almost all the time, so most of the work done by all those
Math.hypot and Math.atan2 (stupid name) calls is usually wasted.
You might decide to defer the work until and unless someone
shows an interest in the polar coordinates. Internally you might
maintain a polarIsUpToDate boolean, setting it to false initially
and whenever x or y is changed (in their setters). In the getters
for rho and theta you'd check polarIsUpToDate and recompute rho
and theta if needed before returning their values. Voila! No
square roots and arctangents unless they're actually necessary.
In more abstract terms, what you've just done is exploit the
separation between interface and implementation that the getters
and setters provide. That in itself can turn out to be more than
enough reason to use them.
--
Eric Sosman
esosman@acm-dot-org.invalid