CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
| Bruce Eckel’s Thinking in Java | Contents | Prev | Next |
A
primary consideration in object-oriented design is “separating the things
that change from the things that stay the same.”
primary consideration in object-oriented design is “separating the things
that change from the things that stay the same.”
This
is particularly important for libraries. The user (
client
programmer
)
of that library must be able to rely on the part they use, and know that they
won’t need to rewrite code if a new version of the library comes out. On
the flip side, the library creator must have the freedom to make modifications
and improvements with the certainty that the client programmer’s code
won’t be affected by those changes.
is particularly important for libraries. The user (
client
programmer
)
of that library must be able to rely on the part they use, and know that they
won’t need to rewrite code if a new version of the library comes out. On
the flip side, the library creator must have the freedom to make modifications
and improvements with the certainty that the client programmer’s code
won’t be affected by those changes.
This
can be achieved through convention. For example, the library programmer must
agree to not remove existing methods when modifying a class in the library,
since that would break the client programmer’s code. The reverse
situation is thornier, however. In the case of a data member, how can the
library creator know which data members have been accessed by client
programmers? This is also true with methods that are only part of the
implementation of a class, and not meant to be used directly by the client
programmer. But what if the library creator wants to rip out an old
implementation and put in a new one? Changing any of those members might break
a client programmer’s code. Thus the library creator is in a strait
jacket and can’t change anything.
can be achieved through convention. For example, the library programmer must
agree to not remove existing methods when modifying a class in the library,
since that would break the client programmer’s code. The reverse
situation is thornier, however. In the case of a data member, how can the
library creator know which data members have been accessed by client
programmers? This is also true with methods that are only part of the
implementation of a class, and not meant to be used directly by the client
programmer. But what if the library creator wants to rip out an old
implementation and put in a new one? Changing any of those members might break
a client programmer’s code. Thus the library creator is in a strait
jacket and can’t change anything.
To
solve this problem, Java provides access
specifiers
to allow the library creator to say what is available to the client programmer
and what is not. The levels of access
control from “most access” to “least access” are public,
“friendly”
(which has no keyword), protected,
and
private.
From the previous paragraph you might think that, as a library
designer, you’ll want to keep everything as “private” as
possible, and expose only the methods that you want the client programmer to
use. This is exactly right, even though it’s often counterintuitive for
people who program in other languages (especially C) and are used to accessing
everything without restriction. By the end of this chapter you should be
convinced of the value of access control in Java.
solve this problem, Java provides access
specifiers
to allow the library creator to say what is available to the client programmer
and what is not. The levels of access
control from “most access” to “least access” are public,
“friendly”
(which has no keyword), protected,
and
private.
From the previous paragraph you might think that, as a library
designer, you’ll want to keep everything as “private” as
possible, and expose only the methods that you want the client programmer to
use. This is exactly right, even though it’s often counterintuitive for
people who program in other languages (especially C) and are used to accessing
everything without restriction. By the end of this chapter you should be
convinced of the value of access control in Java.
The
concept of a library of components and the control over who can access the
components of that library is not complete, however. There’s still the
question of how the components are bundled together into a cohesive library
unit. This is controlled with the
package
keyword in Java, and the access specifiers are affected by whether a class is
in the same package or in a separate package. So to begin this chapter,
you’ll learn how library components are placed into packages. Then
you’ll be able to understand the complete meaning of the access specifiers.
concept of a library of components and the control over who can access the
components of that library is not complete, however. There’s still the
question of how the components are bundled together into a cohesive library
unit. This is controlled with the
package
keyword in Java, and the access specifiers are affected by whether a class is
in the same package or in a separate package. So to begin this chapter,
you’ll learn how library components are placed into packages. Then
you’ll be able to understand the complete meaning of the access specifiers.
