chapter05.html

来自「java 是一个很好的网络开发环境。由于它是通过解释的方法」· HTML 代码 · 共 1,008 行 · 第 1/5 页

    Assert.is_false((1 + 1) == 2, <font color=#004488>"1 +1 != 2"</font>);
  }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">By changing the <B>package</B>
that&#8217;s imported, you change your code from the debug version to the
production version. This technique can be used for any kind of conditional
code.</FONT><A NAME="_Toc408018498"></A><BR></P></DIV>
<A NAME="Heading168"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
Package caveat</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It&#8217;s worth remembering that
anytime you create a package, you implicitly specify a
<A NAME="Index377"></A><A NAME="Index378"></A>directory structure when you give
the package a name. The package <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&#8217;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&#8217;ll know where the problem
lies.</FONT><A NAME="_Toc375545295"></A><A NAME="_Toc408018499"></A><BR></P></DIV>
<A NAME="Heading169"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Java access specifiers</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The Java
<A NAME="Index379"></A><A NAME="Index380"></A>access specifiers
<A NAME="Index381"></A><B>public</B>, <A NAME="Index382"></A><B>protected</B>
and <A NAME="Index383"></A><B>private</B> are placed in front of each definition
for each member in your class, whether it&#8217;s a data member 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><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">One way or another, everything has
some kind of access specified for it. In the following sections, you&#8217;ll
learn all about the various types of access, starting with the default
access.</FONT><A NAME="_Toc312373840"></A><A NAME="_Toc375545296"></A><A NAME="_Toc408018500"></A><BR></P></DIV>
<A NAME="Heading170"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
&#8220;Friendly&#8221;</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">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 &#8220;friendly.&#8221; It
means that all the other classes in the current package have access to the
friendly member, but to all the classes outside of this package the member
appears to be private. Since a compilation unit &#8211; a file &#8211; can
belong only to a single package, all the classes within a single compilation
unit are automatically friendly with each other. Thus, friendly elements are
also said to have <A NAME="Index384"></A><A NAME="Index385"></A><I>package
access</I>.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Friendly 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 friendly members; e.g. making them &#8220;friends&#8221;) you
&#8220;own&#8221; the code in that package. It makes sense that only code that
you own should have friendly access to other code that you own. You could say
that friendly 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 willy-nilly, but in Java you&#8217;re compelled to
<A NAME="Index386"></A><A NAME="Index387"></A>organize them in a sensible
fashion. In addition, you&#8217;ll probably want to exclude classes that
shouldn&#8217;t have access to the classes being defined in the current
package.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">An important question in any
relationship is &#8220;Who can access my <B>private</B> implementation?&#8221;
The class controls which code has access to its members. There&#8217;s no magic
way to &#8220;break in;&#8221; someone in another package can&#8217;t declare a
new class and say, &#8220;Hi, I&#8217;m a friend of <B>Bob</B>&#8217;s!&#8221;
and expect to see the <B>protected</B>, friendly, and <B>private</B> members of
<B>Bob</B>. The only way to grant access to a member is to:</FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Georgia">	Make the member <B>public</B>. Then everybody,
everywhere, can access it.</FONT><LI><FONT FACE="Georgia">	Make the member
friendly by leaving off any access specifier, and put the other classes in the
same package. Then the other classes can access the
member.</FONT><LI><FONT FACE="Georgia">	As you&#8217;ll see in a later
chapter where 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 friendly members only if the two classes
are in the same package. But don&#8217;t worry about that
now.</FONT><LI><FONT FACE="Georgia">	Provide
&#8220;accessor/mutator&#8221; methods (also known as &#8220;get/set&#8221;
methods) that read and change the value. This is the most civilized approach in
terms of OOP, and it is fundamental to Java Beans, as you&#8217;ll see in
Chapter
13.</FONT><A NAME="_Ref351419800"></A><A NAME="_Toc375545297"></A><A NAME="_Toc408018501"></A></OL><A NAME="Heading171"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
public: interface access</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">When you use the <B>public</B>
keyword, it <A NAME="Index388"></A>means that the member declaration that
immediately follows <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><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: 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> foo() { System.out.println(<font color=#004488>"foo"</font>); }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Remember, <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&#8217;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&#8217;t have a &#8216;<B>.</B>&#8217; as one of the paths in your CLASSPATH,
Java won&#8217;t look there.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Now if you create a program that
uses <B>Cookie</B>:</FONT><BR></P></DIV>

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

<font color=#0000ff>public</font> <font color=#0000ff>class</font> Dinner {
  <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.foo(); // Can't access</font>
  }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You can create a <B>Cookie</B>
object, since its constructor is <B>public</B> and the class is <B>public</B>.
(We&#8217;ll look more at the concept of a public class later.) However, the
<B>foo(&#160;)</B> member is inaccessible inside <B>Dinner.java</B> since
<B>foo(&#160;)</B> is friendly only within package
<B>dessert</B>.</FONT><BR></P></DIV>
<A NAME="Heading172"></A><FONT FACE = "Verdana"><H4 ALIGN="LEFT">
The default
package<BR><A NAME="Index389"></A><A NAME="Index390"></A><A NAME="Index391"></A></H4></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You might be surprised to discover
that the following code compiles, even though it would appear that it breaks the
rules:</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: Cake.java</font>
<font color=#009900>// Accesses a class in a separate </font>
<font color=#009900>// compilation unit.</font>

<font color=#0000ff>class</font> Cake {
  <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();
  }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In a second file, in the same
directory:</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: Pie.java</font>
<font color=#009900>// The other class</font>

<font color=#0000ff>class</font> Pie {
  <font color=#0000ff>void</font> f() { System.out.println(<font color=#004488>"Pie.f()"</font>); }
} <font color=#009900>///:~</font></PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You might initially view these as
completely foreign files, and yet <B>Cake</B> is able to create a <B>Pie</B>
object and call its <B>f(&#160;)</B> method! You&#8217;d typically think that
<B>Pie</B> and <B>f(&#160;)</B> are friendly and therefore not available to
<B>Cake</B>. They <I>are</I> friendly &#8211; that part is correct. The reason
that they are available in <B>Cake.java</B> is because they are in the same
directory and have no explicit package name. Java treats files like this as
implicitly part of the &#8220;default package&#8221; for that directory, and
therefore friendly to all the other files in that
directory.</FONT><A NAME="_Toc375545298"></A><A NAME="_Toc408018502"></A><BR></P></DIV>
<A NAME="Heading173"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
private: you can&#8217;t touch that!</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The <B>private</B>
<A NAME="Index392"></A>keyword that means no one can access that member except
that particular class, inside methods of that class. Other classes in the same
package cannot access <B>private </B>members, so it&#8217;s as if you&#8217;re
even insulating the class against yourself. On the other hand, it&#8217;s not
unlikely that a package might be created by several people collaborating
together, so <B>private</B> allows you to freely change that member without
concern that it will affect another class in the same package. The default
&#8220;friendly&#8221; package access is often an adequate amount of hiding;
remember, a &#8220;friendly&#8221; member is inaccessible to the user of the
package. This is nice, since the default access is the one that you normally
use. Thus, you&#8217;ll typically think about access for the members that you
explicitly want to make <B>public</B> for the client programmer, and as a
result, you might not<I> </I>initially think you&#8217;ll use the <B>private
</B>keyword often since it&#8217;s tolerable to get away without it. (This is a
distinct contrast with C++.) However, it turns out that the consistent use of
<B>private</B> is very important, especially where multithreading is concerned.
(As you&#8217;ll see in Chapter 14.)</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Here&#8217;s an example of the use
of <B>private</B>:</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>//: IceCream.java</font>
<font color=#009900>// Demonstrates "private" keyword</font>

<font color=#0000ff>class</font> Sundae {
  <font color=#0000ff>private</font> Sundae() {}
  <font color=#0000ff>static</font> Sundae makeASundae() { 
    <font color=#0000ff>return</font> <font color=#0000ff>new</font> Sundae(); 
  }
}

<font color=#0000ff>public</font> <font color=#0000ff>class</font> IceCream {
  <font color=#0000ff>public</font> <font color=#0000ff>static</font> <font color=#0000ff>void</font> main(String[] args) {
    <font color=#009900>//! Sundae x = new Sundae();</font>