📄 chap05.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:TIJ2.rtf
Application Directory:C:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:05/21/2001
Translation Time:10:39:08
Translation Platform:Win32
Number of Output files:23
This File:Chap05.htm
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>5: Hiding the Implementation</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README.txt">Viewing Hints</a> ]
[ <a href="RevHist.htm">Revision History</a> ]
[ <a href="http://www.mindview.net/Books/TIJ/">Book Home Page</a> ]
[ <a href="http://www.mindview.net/Etc/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Seminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CDs">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/Services">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 2nd edition, Revision 12</FONT></H2>
<H3><FONT FACE="Verdana">©2000 by Bruce Eckel</FONT></H3>
<FONT FACE="Verdana" size = "-1">
[ <a href="Chap04.htm">Previous Chapter</a> ]
[ <a href="SimpCont.htm">Short TOC</a> ]
[ <a href="Contents.htm">Table of Contents</a> ]
[ <a href="DocIdx.htm">Index</a> ]
[ <a href="Chap06.htm">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="Chapter_5"></A><A NAME="_Toc375545290"></A><A NAME="_Toc477690725"></A><A NAME="_Toc481064588"></A><A NAME="Heading189"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
5: Hiding the Implementation</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia" SIZE=4><backtalk:display ID=TIJ3_CHAPTER5_I0>
A primary
consideration in object-oriented design is “separating the things that
change from the things that stay the same.”</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This is particularly important for
libraries. The user (<I>client programmer<A NAME="Index464"></A></I>) 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<A NAME="Index465"></A> 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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I0'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I1>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I1'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I2>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">To solve this problem, Java provides
<A NAME="Index466"></A><A NAME="Index467"></A><I>access specifiers</I> to allow
the library creator to say what is available to the client programmer and what
is not. The levels of <A NAME="Index468"></A>access control from “most
access” to “least access” are
<A NAME="Index469"></A><B>public</B>, <B>protected</B>,
“<A NAME="Index470"></A>friendly” (which has no keyword),
<A NAME="Index471"></A>and<B> <A NAME="Index472"></A>private</B>. From the
previous paragraph you might think that, as a
<A NAME="Index473"></A><A NAME="Index474"></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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I2'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I3>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">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
<B>package</B> 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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I3'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I4>
</FONT><A NAME="_Toc375545291"></A><A NAME="_Toc481064589"></A><BR></P></DIV>
<A NAME="Heading190"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
package: the library unit</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A <A NAME="Index475"></A>package is what
you get when you use the <A NAME="Index476"></A><B>import</B> keyword to bring
in an entire library, such as</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>import</font> java.util.*;</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This brings in the entire utility
<A NAME="Index477"></A>library that’s part of the standard Java
distribution. Since, for example, the class <B>ArrayList</B> is in
<B>java.util</B>, you can now either specify the full name
<B>java.util.ArrayList</B> (which you can do without the <B>import</B>
statement), or you can simply say <B>ArrayList</B> (because of the
<B>import</B>).
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I4'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I5>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If you want to bring in a single class,
you can name that class in the <B>import</B> statement</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>import</font> java.util.ArrayList;</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Now you can use <B>ArrayList</B> with no
qualification. However, none of the other classes in <B>java.util</B> are
available.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I5'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I6>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The reason for all this importing is to
provide a mechanism to manage “<A NAME="Index478"></A>name spaces.”
The names of all your class members are insulated from each other. A method
<B>f( )</B> inside a class <B>A</B> will not <A NAME="Index479"></A>clash
with an <B>f( )</B> that has the same signature (argument list) in class
<B>B</B>. But what about the class names? Suppose you create a <B>stack</B>
class that is installed on a machine that already has a <B>stack</B> class
that’s written by someone else? With Java on the Internet, this can happen
without the user knowing it, since classes can get downloaded automatically in
the process of running a Java program.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I6'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I7>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This potential clashing of names is why
it’s important to have complete control over the name spaces in Java, and
to be able to create a completely unique name regardless of the constraints of
the Internet.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I7'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I8>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">So far, most of the examples in this book
have existed in a single file and have been designed for local use, and
haven’t bothered with package names. (In this case the class name is
placed in the “default package.”) This is certainly an option, and
for simplicity’s sake this approach will be used whenever possible
throughout the rest of this book. However, if you’re planning to create
libraries or programs that are friendly to other Java programs on the same
machine, you must think about preventing class name clashes.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I8'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I9>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">When you create a source-code file for
Java, it’s commonly called a <A NAME="Index480"></A><I>compilation
unit</I> (sometimes a <A NAME="Index481"></A><I>translation unit</I>). Each
compilation unit must have a name ending in <B>.java</B>, and inside the
compilation unit there can be a <B>public</B> class that must have the same name
as the file (including capitalization, but excluding the <B>.java</B> filename
extension). There can be only<I> one</I>
<A NAME="Index482"></A><A NAME="Index483"></A><B>public</B> class in each
compilation unit, otherwise the compiler will complain. The rest of the classes
in that compilation unit, if there are any, are hidden from the world outside
that package because they’re <I>not</I> <B>public</B>, and they comprise
“support” classes for the main <B>public</B> class.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER5_I9'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER5_I10>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">When you compile a <B>.java</B> file you
get an output file with exactly the same name but an extension of <B>.class</B>
<I>for each class in the </I><B>.java</B> file. Thus you can end up with quite a
few <B>.class</B> files from a small number of <B>.java</B> files. If
you’ve programmed with a compiled language, you might be used to the
compiler spitting out an intermediate form (usually an “obj” file)
that is then packaged together with others of its kind using a linker (to create
an executable file) or a librarian (to create a library). That’s not how
Java works. A working program is a bunch of <B>.class</B> files, which can be
packaged and compressed into a <A NAME="Index484"></A><A NAME="Index485"></A>JAR
file (using Java’s <B>jar </B>archiver). The Java interpreter is
responsible for finding, loading, and interpreting these
files</FONT><A NAME="fnB32" HREF="#fn32">[32]</A><FONT FACE="Georgia">.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -