The hidden implementation

Bruce Eckel’s Thinking in Java Contents | Prev | Next

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.

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.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read