chapter05.html
来自「java 是一个很好的网络开发环境。由于它是通过解释的方法」· HTML 代码 · 共 1,008 行 · 第 1/5 页
HTML
1,008 行
<!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:Tjava14.rtf
Application Directory:c:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:02/04/2000
Translation Time:23:24:48
Translation Platform:Win32
Number of Output files:27
This File:Chapter05.html
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-head.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README-HTML.txt">Viewing Hints</a> ]
[ <a href="http://www.mindview.net/TIJ2/index.html">2nd Edition</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Training.html">Seminars</a> ]
[ <a href="http://www.mindview.net/javaCD2.html">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 1st edition</FONT></H2>
<H3><FONT FACE="Verdana">©1998 by Bruce Eckel</FONT></H3>
<FONT FACE="Verdana" size = "-1">
[ <a href="Chapter04.html">Previous Chapter</a> ]
[ <a href="SimpleContents.html">Short TOC</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="Chapter06.html">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="Chapter_5"></A><A NAME="_Toc375545290"></A><A NAME="_Toc407441449"></A><A NAME="_Toc408018493"></A><A NAME="Heading160"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
5: Hiding the implementation</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>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</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
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.</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.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">To solve this problem, Java
provides <A NAME="Index344"></A><A NAME="Index345"></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="Index346"></A>access control from
“most access” to “least access” are
<A NAME="Index347"></A><B>public</B>,
“<A NAME="Index348"></A>friendly” (which has no keyword),
<A NAME="Index349"></A><B>protected</B>, and<B>
<A NAME="Index350"></A>private</B>. From the previous paragraph you might think
that, as a <A NAME="Index351"></A><A NAME="Index352"></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.</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.</FONT><A NAME="_Toc375545291"></A><A NAME="_Toc408018494"></A><BR></P></DIV>
<A NAME="Heading161"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
package: the library unit</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A <A NAME="Index353"></A>package is
what you get when you use the <A NAME="Index354"></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="Index355"></A>library that’s part of the standard Java
distribution. Since <B>Vector</B> is in <B>java.util</B>, you can now either
specify the full name <B>java.util.Vector</B> (which you can do without the
<B>import</B> statement), or you can simply say <B>Vector</B> (because of the
<B>import</B>).</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.Vector;</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Now you can use <B>Vector</B> with
no qualification. However, none of the other classes in <B>java.util</B> are
available.</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="Index356"></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="Index357"></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.</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.</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 the book. If you’re planning to create a program
that is “Internet friendly,” however, you must think about
preventing class name clashes.</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="Index358"></A><I>compilation
unit</I> (sometimes a <A NAME="Index359"></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 public class that must have the same name as the
file (including capitalization, but excluding the <B>.java</B> filename
extension). If you don’t do this, the compiler will complain. There can be
only<I> one</I> <A NAME="Index360"></A><A NAME="Index361"></A><B>public</B>
class in each compilation unit (again, 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.</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="Index362"></A><A NAME="Index363"></A>JAR file (using the <B>jar
</B>utility in Java 1.1<A NAME="Index364"></A>). The Java interpreter is
responsible for finding, loading and interpreting these
files.</FONT><A NAME="fnB23" HREF="#fn23">[23]</A><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A library is also a bunch of these
class files. Each file has one class that is <B>public</B> (you’re not
forced to have a <B>public</B> class, but it’s typical), so there’s
one component for each file. If you want to say that all these components (that
are in their own separate <B>.java </B>and <B>.class </B>files) belong together,
that’s where the <B>package</B> keyword comes in.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">When you say:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>package</font> mypackage;</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">at the beginning of a file, where
the <B>package </B>statement <I>must </I>appear as the first non-comment in the
file, you’re stating that this compilation unit is part of a library named
<B>mypackage</B>. Or, put another way, you’re saying that the
<B>public</B> class name within this compilation unit is under the umbrella of
the name <B>mypackage</B>, and if anyone wants to use the name they must either
fully specify the name or use the <B>import</B> keyword in combination with
<B>mypackage</B> (using the choices given previously). Note that the convention
for Java packages is to use all lowercase letters, even for intermediate
words.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">For example, suppose the name of
the file is <B>MyClass.java</B>. This means there can be one and only one
<B>public</B> class in that file, and the name of that class must be
<B>MyClass</B> (including the capitalization):</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>package</font> mypackage;
<font color=#0000ff>public</font> <font color=#0000ff>class</font> MyClass {
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?