Re: What's the use of private?
Joshua Cranmer wrote:
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.
I can't think of any scenario where private would be a better choice
than protected. So what's the use of private?
Public, package-protected, and protected methods and variables all make
up part of the API for a class. Once you have made a method or variable
any of these types, it becomes a part that *anyone* could use or modify.
You lose some defensiveness. An example helps here:
Suppose that a class, say Widget, has to perform some hairy magic with a
native object peer. People can extend this Widget class to perform
specific tasks, but they don't need to know how to get from Widget's API
to this peer object. Especially, they shouldn't be touching this peer
object. So Widget makes this object peer private to stop people from
touching it.
In addition, variables should almost always be marked private, since
that allows the class to meter access to them for sanity checks and
whatnot.
Here's another way of looking at the situation. In practice, a program
goes on changing throughout its useful lifetime. The requirements at end
of life are almost impossible to predict during initial design. A lot of
software engineering is about how to make unanticipated changes as easy
as possible.
There are two ways to be wrong:
1. Make something private that should have been protected.
2. Make something protected that should have been private.
Which is easier to fix?
In case 1, the programmer examines the class and decides the best way to
provide the protected feature, which may be as simple as changing
"private" to "protected" on an existing method. The implementation of
the change is within one class and its unit test.
In case 2, the programmer is trying to make a change to the
implementation of the class that is prevented because of the commitment
implied by making the method protected. Some of the extending classes
may be implemented by different companies, and the programmer does not
necessarily know about them, let alone have the power to cause changes
in them. The programmer has to either make the permission change, and
suffer the wrath of owners of subclasses, or workaround the problem,
possibly making the design of the class messier than would otherwise be
the case.
Patricia