Access
control is often referred to as
implementation
hiding
.
Wrapping data and methods within classes (combined with implementation hiding
this is often called
encapsulation
)
produces a data type with characteristics and behaviors, but access control
puts boundaries within that data type for two important reasons. The first is
to establish what the client programmers can and can’t use. You can build
your internal mechanisms into the structure without worrying that the client
programmers will think it’s part of the interface that they should be
using.
This
feeds directly into the second reason, which is to separate the interface from
the implementation.
If the structure is used in a set of programs, but users can’t do
anything but send messages to the
public
interface, then you can change anything that’s
not
public
(e.g. “friendly,”
protected,
or
private)
without requiring modifications to their code.
We’re
now in the world of object-oriented programming, where a
class
is actually describing “a class of objects,” as you would describe
a class of fishes or a class of birds. Any object belonging to this class will
share these characteristics and behaviors. The class is a description of the
way all objects of this type will look and act.
In
the original OOP
language,Simula-67,
the keyword
class
was
used to describe a new data type. The same keyword has been used for most
object-oriented languages. This is the focal point of the whole language: the
creation of new data types that are more than just boxes containing data and
methods.
The
class is the fundamental OOP concept in Java. It is one of the keywords that
will
not
be
set in bold in this book – it becomes annoying with a word repeated as
often as “class.”
For
clarity, you might prefer a
of creating classes that puts the
public
members at the beginning, followed by the
protected,
friendly and
private
members. The advantage is that the user of the class can then read down from
the top and see first what’s important to them (the
public
members, because they can be accessed outside the file) and stop reading when
they encounter the non-public members, which are part of the internal
implementation. However, with the comment documentation supported by javadoc
(described in Chapter 2) the issue of code readability by the client programmer
becomes less important.
public class X {
public void pub1( ) { /* . . . */ }
public void pub2( ) { /* . . . */ }
public void pub3( ) { /* . . . */ } <p><tt> private void priv1( ) { /* . . . */ } </tt></p><p><tt> private void priv2( ) { /* . . . */ } </tt></p><p><tt> private void priv3( ) { /* . . . */ } </tt></p><p><tt> private int i; </tt></p><p><tt> // . . . </tt></p><p><tt>}</tt></p>
This
will make it only partially easier to read because the interface and
implementation are still mixed together. That is, you still see the source code
– the implementation – because it’s right there in the class.
Displaying the interface to the consumer of a class is really the job of the
classbrowser
,
a tool whose job is to look at all the available classes and show you what you
can do with them (i.e. what members are available) in a useful fashion. By the
time you read this, good browsers should be an expected part of any good Java
development tool.
Contents
|
Prev|
Next