Re: What's the use of private?
Jeff.M wrote:
Unless I'm mistaken, private things are inaccessible to everything
else, even subclasses. And it seems that using private makes it
difficult, if not impossible, to extend the class. Protected, on the
other hand, is just like private except that extending classes can use
protected things.
Extending a class is done for very specific reasons and is not a
"one-size-fits-all" technique. As Joshua Bloch points out in /Effective
Java/, one should prefer composition - including a reference to another class
instance - to inheritance.
Keeping methods and instances private not only does not make extending a class
harder, it makes extending a class easier. There is less to extend, and fewer
unintended consequences.
I can't think of any scenario where private would be a better choice
than protected. So what's the use of private?
Most variables in a class should be restricted to private accessibility. Some
methods may be, if they provide internal services to the class or its instances.
This supports the fundamental object-oriented design and programming principle
of "encapsulation" and "information hiding". The details of how a class
implements behavior should be private whenever possible.
Public and protected variables and methods, and to a lesser extent
package-private accessible elements, become part of the class's outer face,
the contract that it must fulfill forever and in all incarnations. Hidden
elements are easier to maintain because they do not affect the rest of the
world directly. When you open access to an element you commit forever to
having that element available to users of the class.
It is a best practice to program to an interface and implement that interface
with no additional public methods.
Private methods help keep the internal structure of a class maintainable and
easy to understand. Otherwise you end up with tangled mega-methods that try
to do too much in one routine.
Private instance variables can be accessed through accessor methods
("getters") and mutator methods ("setters"). Such methods can enforce program
invariants, control side effects, and perhaps even obviate the need for an
instance variable altogether.
Consider an analogy. When you post a (snail-mail) letter at the post office,
you drop it in a box or hand it to a postal clerk. You don't know or care
whether they use a private method of airplane, truck or pony to get the letter
to its destination. They are free to implement different methods /ad lib./.
The precise delivery mechanism is private; the action to "post( Letter letter
)" is public. If ponies become obsolete in favor of suborbital rockets, all
you experience is better service. The postal system is not obligated to
maintain its postal stables because they never made the pony system public.
Hunt around for tutorials on object-oriented programming practices and you
will find better and more complete explanations.
--
Lew