📄 tij307.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">
<!--
This document was converted from RTF source:
By r2net 5.8 r2netcmd Windows
See http://www.logictran.com
-->
<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Thinking in Java, 3rd ed. Revision 4.0: 5: Hiding the Implementation</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css"></head>
<body >
<CENTER> <a href="http://www.MindView.net"> <img src="mindview.gif" alt="MindView Inc." BORDER = "0"></a> <Font FACE="Verdana, Tahoma, Arial, Helvetica, Sans"> <h2>Thinking in Java, 3<sup>rd</sup> ed. Revision 4.0</h2> <FONT size = "-1"><br> [ <a href="README.txt">Viewing Hints</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> ] <br><br> </FONT></FONT> </CENTER>
<font face="Georgia"><div align="CENTER"><a href="TIJ306.htm" target="RightFrame"><img src="./prev.gif" alt="Previous " border="0"></a>
<a href="TIJ308.htm" target="RightFrame"><img src="./next.gif" alt="Next " border="0"></a>
<a href="TIJ3_t.htm"><img src="./first.gif" alt="Title Page " border="0"></a>
<a href="TIJ3_i.htm"><img src="./index.gif" alt="Index " border="0"></a>
<a href="TIJ3_c.htm"><img src="./contents.gif" alt="Contents " border="0"></a>
</div>
<hr>
<h1>
<a name="_Toc375545290"></a><a name="_Toc24272644"></a><a name="_Toc24775619"></a><a name="Heading4619"></a>5:
Hiding the Implementation</h1>
<p class="Intro">A primary consideration in object-oriented design is “separating the things that change from the things that stay the same.”<br></p>
<p>This is particularly important for libraries. Users (<i>client programmers</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 code won’t be affected by those changes. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_814" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index406"></a><a name="Index407"></a>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 field, how can the library creator know which fields 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 size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_815" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>To solve this problem, Java provides <a name="Index408"></a><a name="Index409"></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 access control from “most access” to “least access” are <a name="Index410"></a><a name="Index411"></a><b>public</b>, <b>protected</b>, package access (which has no keyword), and<a name="Index412"></a><b> private</b><a name="Index413"></a>. 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. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_816" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index414"></a><a name="Index415"></a>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 size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_817" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc375545291"></a><a name="_Toc24775620"></a><a name="Heading4625"></a>package:
the library unit</h2>
<p>A package is what becomes available when you use the <a name="Index416"></a><a name="Index417"></a><b>import</b> keyword to bring in an entire library, such as<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>import</font> java.util.*;</PRE></FONT></BLOCKQUOTE><p><br></p>
<p>This brings in the entire utility library that’s part of the standard Java distribution. For instance, there’s a class called <a name="Index418"></a><b>ArrayList</b> in <b>java.util</b>, so 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>). <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_818" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>If you want to bring in a single class, you can name that class in the <b>import</b> statement<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>import</font> java.util.ArrayList;</PRE></FONT></BLOCKQUOTE><p><br></p>
<p>Now you can use <b>ArrayList</b> with no qualification. However, none of the other classes in <b>java.util</b> are available. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_819" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>The reason for all this importing is to provide a mechanism to manage <a name="Index419"></a><a name="Index420"></a><i>name spaces</i>. 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 clash with an <a name="Index421"></a><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? 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 size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_820" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Most of the examples thus far in this book have existed in a single file and have been designed for local use, so they 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. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_822" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>When you create a source-code file for Java, it’s commonly called a <a name="Index422"></a><i>compilation unit</i> (sometimes a <a name="Index423"></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="Index424"></a><a name="Index425"></a><b>public</b> class in each compilation unit, otherwise the compiler will complain. If there are additional classes in that compilation unit, they 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 size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_823" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>When you compile a <b>.java</b> file, you get an output file <i>for each class in the </i><b>.java</b> file. Each output file has the name of a class in the <b>.java </b>file, but with an extension of <b>.class</b>. 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 Java ARchive (JAR) file (using Java’s <a name="Index426"></a><a name="Index427"></a><b>jar </b>archiver). The Java interpreter is responsible for finding, loading, and interpreting<sup><a name="fnB26" href="#fn26">[26]</a></sup> these files. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_824" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>A library is a group 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 (each 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 size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_825" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>When you say:<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>package</font> mypackage;</PRE></FONT></BLOCKQUOTE><p><br></p>
<p>at the beginning of a file (if you use a <b>package </b>statement, it <i>must </i>appear as the first noncomment 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 anyone who wants to use the name 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 package names is to use all lowercase letters, even for intermediate words. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_826" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>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):<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>package</font> mypackage;
<font color=#0000ff>public</font> <font color=#0000ff>class</font> MyClass {
<font color=#009900>// . . .</font></PRE></FONT></BLOCKQUOTE><p><br></p>
<p>Now, if someone wants to use <b>MyClass</b> or, for that matter, any of the other <b>public</b> classes in <b>mypackage</b>, they must use the <b>import</b> keyword to make the name or names in <b>mypackage</b> available. The alternative is to give the fully qualified name:<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE>mypackage.MyClass m = <font color=#0000ff>new</font> mypackage.MyClass();</PRE></FONT></BLOCKQUOTE><p><br></p>
<p>The <b>import</b> keyword can make this much cleaner:<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>import</font> mypackage.*;
<font color=#009900>// . . . </font>
MyClass m = <font color=#0000ff>new</font> MyClass();</PRE></FONT></BLOCKQUOTE><p><br></p>
<p>It’s worth keeping in mind that what the <b>package</b> and <b>import</b> keywords allow you to do, as a library designer, is to divide up the single global name space so you won’t have clashing names, no matter how many people get on the Internet and start writing classes in Java. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_827" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc375545292"></a><a name="_Toc24775621"></a><a name="Heading4658"></a>Creating
unique package names</h3>
<p>You might observe that, since a package never really gets “packaged” into a single file, a package could be made up of many <b>.class</b> files, and things could get a bit cluttered. To prevent this, a logical thing to do is to place all the <b>.class</b> files for a particular package into a single directory; that is, use the hierarchical file structure of the operating system to your advantage. This is one way that Java references the problem of clutter; you’ll see the other way later when the <b>jar</b> utility is introduced. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_828" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index428"></a><a name="Index429"></a>Collecting the package files into a single subdirectory solves two other problems: creating unique package names, and finding those classes that might be buried in a directory structure someplace. This is accomplished, as was introduced in Chapter 2, by encoding the path of the location of the <b>.class</b> file into the name of the <b>package</b>. By convention, the first part of the <b>package</b> name is the reversed Internet domain name of the creator of the class. Since Internet domain names are guaranteed to be unique, <i>if</i> you follow this convention, your <b>package</b> name will be unique and you’ll never have a name clash. (That is, until you lose the domain name to someone else who starts writing Java code with the same path names as you did.) Of course, if you don’t have your own domain name, then you must fabricate an unlikely combination (such as your first and last name) to create unique package names. If you’ve decided to start publishing Java code, it’s worth the relatively small effort to get a domain name. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_829" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>The second part of this trick is resolving the <b>package</b> name into a directory on your machine, so when the Java program runs and it needs to load the <a name="Index430"></a><a name="Index431"></a><b>.class </b>file (which it does dynamically, at the point in the program where it needs to create an object of that particular class, or the first time you access a <b>static </b>member of the class), it can locate the directory where the <b>.class </b>file resides. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_830" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>The Java interpreter proceeds as follows. First, it finds the environment variable CLASSPATH<a name="Index432"></a><sup><a name="fnB27" href="#fn27">[27]</a></sup> (set via the operating system, and sometimes by the installation program that installs Java or a Java-based tool on your machine). CLASSPATH contains one or more directories that are used as roots in a search for <b>.class</b> files. Starting at that root, the interpreter will take the package name and replace each dot with a slash to generate a path name from the CLASSPATH root (so <b>package foo.bar.baz</b> becomes <b>foo\bar\baz </b>or <b>foo/bar/baz </b>or possibly something else, depending on your operating system). This is then concatenated to the various entries in the CLASSPATH. That’s where it looks for the <b>.class</b> file with the name corresponding to the class you’re trying to create. (It also searches some standard directories relative to where the Java interpreter resides). <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_831" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>To understand this, consider my domain name, which is <b>bruceeckel.com</b>. By reversing this, <b>com.bruceeckel</b> establishes my unique global name for my classes. (The com, edu, org, etc., extensions were formerly capitalized in Java packages, but this was changed in Java 2 so the entire package name is lowercase.) I can further subdivide this by deciding that I want to create a library named <b>simple</b>, so I’ll end up with a package name:<br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>package</font> com.bruceeckel.simple;</PRE></FONT></BLOCKQUOTE><p><br></p>
<p>Now this package name can be used as an umbrella name space for the following two files: <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_832" title="Send BackTalk Comment">Feedback</a></font><br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: com:bruceeckel:simple:Vector.java</font>
<font color=#009900>// Creating a package.</font>
<font color=#0000ff>package</font> com.bruceeckel.simple;
<font color=#0000ff>public</font> <font color=#0000ff>class</font> Vector {
<font color=#0000ff>public</font> Vector() {
System.out.println(<font color=#004488>"com.bruceeckel.simple.Vector"</font>);
}
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE><p><br></p>
<p>When you create your own packages, you’ll discover that the <b>package</b> statement must be the first noncomment code in the file. The second file looks much the same: <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap05_833" title="Send BackTalk Comment">Feedback</a></font><br></p>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: com:bruceeckel:simple:List.java</font>
<font color=#009900>// Creating a package.</font>
<font color=#0000ff>package</font> com.bruceeckel.simple;
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -