The hidden implementation

It is helpful to break up the playing field into class creators (those who create new data
types) and client programmers4 (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.
4 I’m indebted to my friend Scott Meyers for this term.
Light
on( )
off( )
brighten( )
dim( )
Type Name
Interface
Chapter 1: Introduction to Objects 45
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 to members. 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.