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 user of that library – the client programmer – who is
another programmer, but one putting together an application or using your
library to build a bigger library.
Without
rules, client programmers can do anything they want with all the members of a
class, even if you might prefer they don’t directly manipulate some of
the members. Everything’s naked to the world.
This
chapter looked at how classes are built to form libraries; first, the way a
group of classes is packaged within a library, and second, the way the class
controls access to its members.
It
is estimated that a C programming project begins to break down somewhere
between 50K and 100K lines of code because C has a single “name
space” so names begin to collide, causing an extra management overhead.
In Java, the
package
keyword, the package naming scheme and the
import
keyword give you complete control over names, so the issue of name collision is
easily avoided.
There
are two reasons for controlling access to
members. The first is to keep users’ hands off tools that they
shouldn’t touch; tools 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. So making methods and fields private is a service to users
because they can easily see what’s important to them and what they can
ignore. It simplifies their understanding of the class.
The
second and most important reason for access control is to allow the library
designer to change the internal workings of the class without worrying about
how it will affect the client programmer. You might build a class one way at
first, and then discover that restructuring your code will provide much greater
speed. If the interface and implementation are clearly separated and protected,
you can accomplish this without forcing the user to rewrite their code.
Access
specifiers in Java give valuable control to the creator of a class. The users
of the class can clearly see exactly what they can use and what to ignore. More
important, though, is the ability to ensure that no user becomes dependent on
any part of the underlying implementation of a class. If you know this as the
creator of the class, you can change the underlying implementation with the
knowledge that no client programmer will be affected by the changes because
they can’t access that part of the class.
When
you have the ability to change the underlying implementation, you can not only
improve your design later,
but you also have the freedom to make mistakes.
No matter how carefully you plan and design you’ll make mistakes. Knowing
that it’s relatively safe to make these mistakes means you’ll be
more experimental, you’ll learn faster and you’ll finish your
project sooner.
The
public interface to a class is what the user
does
see, so that is the most important part of the class to get “right”
during analysis and design. Even that allows you some leeway for change. If you
don’t get the interface right the first time, you can
add
more methods,
as long as you don’t remove any that client programmers have already used
in their code.