It
is helpful to break up the playing field into
class
creators
(those who create new data types) and
client
programmers
[4]
(the class consumers who use the data types in their applications). The goal of
the client programmer is to collect a toolbox full of classes to use for rapid
application development. The goal of the class creator is to build a class that
exposes only what’s necessary to the client programmer and keeps
everything else hidden. Why? If it’s hidden, the client programmer
can’t use it, which means that the class creator can change the hidden
portion at will without worrying about the impact to anyone else.
The
interface establishes
what
requests you can make for a particular object. However, there must be code
somewhere to satisfy that request. This, along with the hidden data, comprises
the
implementation
.
From a procedural programming standpoint, it’s not that complicated. A
type has a function associated with each possible request, and when you make a
particular request to an object, that function is called. This process is often
summarized by saying that you “send a message” (make a request) to
an object, and the object figures out what to do with that message (it executes
code).
In
any relationship it’s important to have boundaries that are respected by
all parties involved. When you create a library, you establish a relationship
with the client
programmer
,who is another programmer, but one who is putting together an application or
using your library to build a bigger library.
If
all the members of a class are available to everyone, then the client
programmer can do anything with that class and there’s no way to force
any particular behaviors. Even though you might really prefer that the client
programmer not directly manipulate some of the members of your class, without
access control there’s no way to prevent it. Everything’s naked to
the world.
There
are two reasons for controlling access
tomembers. The first is to keep client programmers’ hands off portions they
shouldn’t touch – parts that are necessary for the internal
machinations of the data type but not part of the interface that users need to
solve their particular problems. This is actually a service to users because
they can easily see what’s important to them and what they can ignore.
The
second reason for access control is to allow the library designer to change the
internal workings of the structure without worrying about how it will affect
the client programmer. For example, you might implement a particular class in a
simple fashion to ease development, and then later decide you need to rewrite
it to make it run faster. If the interface and implementation are clearly
separated and protected, you can accomplish this and require only a relink by
the user.
Java
uses three explicit keywords and one implied keyword to set the boundaries in a
class:
public
,
private
,
protected
and the implied “friendly,” which is what you get if you
don’t specify one of the other keywords. Their use and meaning are
remarkably straightforward. These
access
specifiers
determine
who can use the definition that follows.
public
means
the following definition is available to everyone. The
private
keyword,
on the other hand, means that no one can access that definition except you, the
creator of the type, inside function members of that type.
private
is a brick wall between you and the client programmer. If someone tries to
access a private member, they’ll get a compile-time error.
“Friendly” has to do with something called a “package,”
which is Java’s way of making libraries. If something is
“friendly” it’s available only within the package. (Thus this
access level is sometimes referred to as “package access.”)
protected
acts just like
private,
with the exception that an inheriting class has access to
protected
members, but not
private
members. Inheritance will be covered shortly.
[4]
I’m indebted to my friend Scott Meyers for this term.
Contents|
Prev|
Next