tij307.htm

这也是我们java老师给我们的thinking in java的一些资料

<h3>
<a name="_Toc375545294"></a><a name="_Toc24775623"></a><a name="Heading4772"></a>Using
imports to change behavior</h3>
<p>A feature that is missing from Java is C&#146;s <i>conditional compilation</i>, which allows you to change a switch and get different behavior without changing any other code. The reason such a feature was left out of Java is probably because it is most often used in C to solve cross-platform issues: Different portions of the code are compiled depending on the platform that the code is being compiled for. Since Java is intended to be automatically cross-platform, such a feature should not be necessary. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_844" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>However, there are other valuable uses for conditional compilation. A very common use is for debugging code. The debugging features are enabled during development and disabled in the shipping product. You can accomplish this by changing the <b>package</b> that&#146;s imported to change the code used in your program from the debug version to the production version. This technique can be used for any kind of conditional code. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_850" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc24775624"></a><a name="Heading4775"></a>Package caveat</h3>
<p>It&#146;s worth remembering that anytime you create a package, you implicitly specify a directory structure when you give the package a name. The package <a name="Index436"></a><a name="Index437"></a><i>must</i> live in the directory indicated by its name, which must be a directory that is searchable starting from the CLASSPATH. Experimenting with the <b>package</b> keyword can be a bit frustrating at first, because unless you adhere to the package-name to directory-path rule, you&#146;ll get a lot of mysterious run-time messages about not being able to find a particular class, even if that class is sitting there in the same directory. If you get a message like this, try commenting out the <b>package</b> statement, and if it runs, you&#146;ll know where the problem lies. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_851" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc375545295"></a><a name="_Toc24775625"></a><a name="Heading4777"></a>Java
access specifiers</h2>
<p>When used, the Java access specifiers <a name="Index438"></a><a name="Index439"></a><a name="Index440"></a><b>public</b>, <a name="Index441"></a><b>protected,</b> and <a name="Index442"></a><b>private</b> are placed in front of each definition for each member in your class, whether it&#146;s a field or a method. Each access specifier controls the access for only that particular definition. This is a distinct contrast to C++, in which the access specifier controls all the definitions following it until another access specifier comes along. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_852" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>One way or another, everything has some kind of access specified for it. In the following sections, you&#146;ll learn all about the various types of access, starting with the default access. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_853" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc24775626"></a><a name="Heading4780"></a>Package access</h3>
<p>What if you give no access specifier at all, as in all the examples before this chapter? The default access has no keyword, but it is commonly referred to as <i>package access </i>(and sometimes &#147;friendly&#148;). It means that all the other classes in the current package have access to that member, but to all the classes outside of this package, the member appears to be <b>private</b>. Since a compilation unit&#151;a file&#151;can belong only to a single package, all the classes within a single compilation unit are automatically available each other via package access. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_854" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index443"></a><a name="Index444"></a>Package access allows you to group related classes together in a package so that they can easily interact with each other. When you put classes together in a package, thus granting mutual access to their package-access members, you &#147;own&#148; the code in that package. It makes sense that only code you own should have package access to other code you own. You could say that package access gives a meaning or a reason for grouping classes together in a package. In many languages the way you organize your definitions in files can be arbitrary, but in Java you&#146;re compelled to organize them in a sensible fashion. In addition, you&#146;ll probably want to exclude classes that shouldn&#146;t have access to the classes being defined in the current package. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_855" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index445"></a><a name="Index446"></a>The class controls which code has access to its members. There&#146;s no magic way to &#147;break in.&#148; Code from another package can&#146;t show up and say, &#147;Hi, I&#146;m a friend of <b>Bob</b>&#146;s!&#148; and expect to see the <b>protected</b>, package-access, and <b>private</b> members of <b>Bob</b>. The only way to grant access to a member is to: <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_856" title="Send BackTalk Comment">Feedback</a></font><br></p>
<ol>
<li>Make the member <b>public</b>. Then everybody, everywhere, can access it.
<font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_857"
title="Send BackTalk Comment">Feedback</a></font></li>
<li>Give the member package access by leaving off any access specifier, and put
the other classes in the same package. Then the other classes in that package
can access the member. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap05_858" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>As you&#146;ll see in Chapter 6, when inheritance is introduced, an
inherited class can access a <b>protected</b> member as well as a <b>public</b>
member (but not <b>private</b> members). It can access package-access members
only if the two classes are in the same package. But don&#146;t worry about
that now. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap05_859" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>Provide &#147;accessor/mutator&#148; methods (also known as
&#147;get/set&#148; methods) that read and change the value. This is the most
civilized approach in terms of OOP, and it is fundamental to JavaBeans, as
you&#146;ll see in Chapter 14. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap05_860" title="Send BackTalk
Comment">Feedback</a></font></li></ol><h3>
<a name="_Ref351419800"></a><a name="_Toc375545297"></a><a name="_Toc24775627"></a><a name="Heading4788"></a><b>public</b>:
interface access</h3>
<p>When you use the <b>public</b> keyword, it means that the member declaration that immediately follows <a name="Index447"></a><b>public</b> is available to everyone, in particular to the client programmer who uses the library. Suppose you define a package <b>dessert</b> containing the following compilation unit: <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_861" title="Send BackTalk Comment">Feedback</a></font><br></p>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: c05:dessert:Cookie.java</font>
<font color=#009900>// Creates a library.</font>
<font color=#0000ff>package</font> c05.dessert;

<font color=#0000ff>public</font> <font color=#0000ff>class</font> Cookie {
  <font color=#0000ff>public</font> Cookie() {
   System.out.println(<font color=#004488>"Cookie constructor"</font>);
  }
  <font color=#0000ff>void</font> bite() { System.out.println(<font color=#004488>"bite"</font>); }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE><p><br></p>
<p>Remember, the class file produced by <b>Cookie.java</b> must reside in a subdirectory called <b>dessert</b>, in a directory under <b>c05 </b>(indicating Chapter 5 of this book) that must be under one of the CLASSPATH directories. Don&#146;t make the mistake of thinking that Java will always look at the current directory as one of the starting points for searching. If you don&#146;t have a &#145;<b>.</b>&#146; as one of the paths in your CLASSPATH, Java won&#146;t look there. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_862" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Now if you create a program that uses <b>Cookie</b>:<br></p>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: c05:Dinner.java</font>
<font color=#009900>// Uses the library.</font>
<font color=#0000ff>import</font> com.bruceeckel.simpletest.*;
<font color=#0000ff>import</font> c05.dessert.*;

<font color=#0000ff>public</font> <font color=#0000ff>class</font> Dinner {
  <font color=#0000ff>static</font> Test monitor = <font color=#0000ff>new</font> Test();
  <font color=#0000ff>public</font> Dinner() {
   System.out.println(<font color=#004488>"Dinner constructor"</font>);
  }
  <font color=#0000ff>public</font> <font color=#0000ff>static</font> <font color=#0000ff>void</font> main(String[] args) {
    Cookie x = <font color=#0000ff>new</font> Cookie();
    <font color=#009900>//! x.bite(); // Can't access</font>
    monitor.expect(<font color=#0000ff>new</font> String[] {
      <font color=#004488>"Cookie constructor"</font>
    });
  }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE><p><br></p>
<p>you can create a <b>Cookie</b> object, since its constructor is <b>public</b> and the class is <b>public</b>. (We&#146;ll look more at the concept of a <b>public</b> class later.) However, the <b>bite(&#160;)</b> member is inaccessible inside <b>Dinner.java</b> since <b>bite(&#160;)</b> provides access only within package <b>dessert</b>, so the compiler prevents you from using it. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap05_863" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h4>
<a name="Heading4823"></a>The default package<br></h4>
<p><a name="Index448"></a><a name="Index449"></a><a name="Index450"></a>You might be surprised to discover that the following code compiles, even though it would appear that it breaks the rules:<br></p>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: c05:Cake.java</font>
<font color=#009900>// Accesses a class in a separate compilation unit.</font>
<font color=#0000ff>import</font> com.bruceeckel.simpletest.*;

<font color=#0000ff>class</font> Cake {
  <font color=#0000ff>static</font> Test monitor = <font color=#0000ff>new</font> Test();
  <font color=#0000ff>public</font> <font color=#0000ff>static</font> <font color=#0000ff>void</font> main(String[] args) {
    Pie x = <font color=#0000ff>new</font> Pie();
    x.f();
    monitor.expect(<font color=#0000ff>new</font> String[] {
      <font color=#004488>"Pie.f()"</font>