Java Reference
In-Depth Information
The second principle— not being allowed to know —is different. It also has to do with modu-
larization, but in a different context. The programming language does not allow access to the
private section of one class by statements in another class. This ensures that one class does not
depend on exactly how another class is implemented.
information hiding
is a principle that
states that internal
details of a class's
should be hidden
from other classes.
It ensures better
modularization of an
This is very important for maintenance work. It is a very common task for a maintenance pro-
grammer to later change or extend the implementation of a class to make improvements or fix
bugs. Ideally, changing the implementation of one class should not make it necessary to change
other classes as well. This issue is known as coupling. If changes in one part of a program do
not make it necessary to also make changes in another part of the program, this is known as
weak coupling or loose coupling. Loose coupling is good, because it makes a maintenance pro-
grammer's job much easier. Instead of understanding and changing many classes, she may only
need to understand and change one class. For example, if a Java systems programmer makes an
improvement to the implementation of the ArrayList class, you would hope that you would
not need to change your code using this class. This will work, because you have not made any
references to the implementation of ArrayList in your own code.
So, to be more precise, the rule that a user should not be allowed to know the internals of a
class does not refer to the programmer of another class, but to the class itself. It is not usually
a problem if a programmer knows the implementation details, but a class should not “know”
(depend on) the internal details of another class. The programmer of both classes might even be
the same person, but the classes should still be loosely coupled.
The issues of coupling and information hiding are very important, and we shall have more to
say about them in later chapters.
For now, it is important to understand that the private keyword enforces information hiding
by not allowing other classes access to this part of the class. This ensures loose coupling and
makes an application more modular and easier to maintain.
Private methods and public fields
Most methods we have seen so far were public. This ensures that other classes can call these
methods. Sometimes, though, we have made use of private methods. In the SupportSystem
class of the TechSupport system, for instance, we saw the methods printWelcome and
printGoodbye declared as private methods.
The reason for having both options is that methods are actually used for different purposes.
They are used to provide operations to users of a class (public methods), and they are used to
break up a larger task into several smaller ones to make the large task easier to handle. In the
second case, the subtasks are not intended to be invoked directly from outside the class, but are
placed in separate methods purely to make the implementation of a class easier to read. In this
case, such methods should be private. The printWelcome and printGoodbye methods are
examples of this.
Another good reason for having a private method is for a task that is needed (as a subtask) in
several of a class's methods. Instead of writing the code multiple times, we can write it once in
a single private method and then call this method from several different places. We shall see an
example of this later.
Search WWH ::

Custom Search