tij0198.html

学习java的经典书籍

mechanism like virtual base classes in C++.
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">To
create a version of the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
that can be instantiated, use the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>implements
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">keyword,
whose syntax looks like inheritance:
</FONT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">public
interface Face {
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 public void smile();
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">}</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">public
class Baz extends Bar implements Face {
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 public void smile(&#160;) {
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
   System.out.println("a warm smile");
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 }
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">}</FONT></TT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	There&#8217;s
no 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>virtual</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
keyword in Java because all non-
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>static</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
methods always use dynamic binding. In Java, the programmer doesn&#8217;t have
to decide whether to use dynamic binding. The reason 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>virtual</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
exists in C++ is so you can leave it off for a slight increase in efficiency
when you&#8217;re tuning for performance (or, put another way, &#8220;If you
don&#8217;t use it, you don&#8217;t pay for it&#8221;), which often results in
confusion and unpleasant surprises. The 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>final</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
keyword provides some latitude for efficiency tuning &#8211; it tells the
compiler that this method cannot be overridden, and thus that it may be
statically bound (and made inline, thus using the equivalent of a C++ non-
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>virtual</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
call). These optimizations are up to the compiler.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Java
doesn&#8217;t provide multiple inheritance (MI), at least not in the same sense
that C++ does. Like 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>protected</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
MI seems like a good idea but you know you need it only when you are face to
face with a certain design problem. Since Java uses a singly-rooted hierarchy,
you&#8217;ll probably run into fewer situations in which MI is necessary. The 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
keyword takes care of combining multiple interfaces.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Run-time
type identification functionality is quite similar to that in C++. To get
information about handle 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>X,</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
you can say, for example:
</FONT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">X.getClass().getName();</FONT></TT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">To
perform a type-safe downcast you say:
</FONT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">derived
d = (derived)base;
</FONT></TT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">just
like an old-style C cast. The compiler automatically invokes the dynamic
casting mechanism without requiring extra syntax. Although this doesn&#8217;t
have the benefit of easy location of casts as in C++ &#8220;new casts,&#8221;
Java checks usage and throws exceptions so it won&#8217;t allow bad casts like
C++ does. 
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Exception
handling in Java is different because there are no destructors. A 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finally</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
clause can be added to force execution of statements that perform necessary
cleanup. All exceptions in Java are inherited from the base class 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Throwable</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
so you&#8217;re guaranteed a common interface.
</FONT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">public
void f(Obj b) throws IOException {
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 myresource mr = b.createResource();
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 try {
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
   mr.UseResource();
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 } catch (MyException e) { 
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
   // handle my exception
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 } catch (Throwable e) { 
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
   // handle all other exceptions
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 } finally {
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
   mr.dispose(); // special cleanup
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">
 }
</FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">}</FONT></TT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Exception
specifications in Java are vastly superior to those in C++. Instead of the C++
approach of calling a function at run-time when the wrong exception is thrown,
Java exception specifications are checked and enforced at compile-time. In
addition, overridden methods must conform to the exception specification of the
base-class version of that method: they can throw the specified exceptions or
exceptions derived from those. This provides much more robust
exception-handling code.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Java
has method overloading, but no operator overloading. The 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>String</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
class does use the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>+</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>+=
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">operators
to concatenate strings and 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>String
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">expressions
use automatic type conversion, but that&#8217;s a special built-in case.
</FONT><a name="OLE_LINK7"></a><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	The
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>const</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
issues in C++ are avoided in Java by convention. You pass only handles to
objects and local copies are never made for you automatically. If you want the
equivalent of C++&#8217;s pass-by-value, 
<a name="OLE_LINK8"></a>you
call 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>clone(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
to produce a local copy of the argument (although the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>clone(&#160;)
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">mechanism
is somewhat poorly designed &#8211; see Chapter 12). There&#8217;s no
copy-constructor that&#8217;s automatically called.
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">To
create a compile-time constant value, you say, for example:
</FONT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black"><B>static
final int SIZE = 255;
</B></FONT></TT><P><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black"><B>static
final int BSIZE = 8 * SIZE;
</B></FONT></TT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Because
of security issues, programming an &#8220;application&#8221; is quite different
from programming an &#8220;applet.&#8221; A significant issue is that an applet
won&#8217;t let you write to disk, because that would allow a program
downloaded from an unknown machine to trash your disk. This changes somewhat
with Java 1.1<A NAME="Index3127"></A>
digital signing, which allows you to unequivocally 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>know</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
everyone that wrote all the programs that have special access to your system
(one of which might have trashed your disk; you still have to figure out which
one and what to do about it.). Java 1.2 also promises more power for applets
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Since
Java can be too restrictive in some cases, you could be prevented from doing
important tasks such as directly accessing hardware. Java solves this with 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>native
methods
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
that allow you to call a function written in another language (currently only C
and C++ are supported). Thus, you can always solve a platform-specific problem
(in a relatively non-portable fashion, but then that code is isolated). Applets
cannot call native methods, only applications.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Java
has built-in support for comment documentation, so the source code file can
also contain its own documentation, which is stripped out and reformatted into
HTML via a separate program. This is a boon for documentation maintenance and
use.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Java
contains standard libraries for solving specific tasks. C++ relies on
non-standard third-party libraries. These tasks include (or will soon include):
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Networking
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Database Connection (via JDBC)
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Multithreading
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Distributed Objects (via RMI and CORBA)
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Compression
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Commerce
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
availability and standard nature of these libraries allow for more rapid
application development.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Java
1.1<A NAME="Index3128"></A>
includes the Java Beans standard, which is a way to create components that can
be used in visual programming environments. This promotes visual components
that can be used under all vendor&#8217;s development environments. Since you
aren&#8217;t tied to a particular vendor&#8217;s design for visual components,
this should result in greater selection and availability of components. In
addition, the design for Java Beans is simpler for programmers to understand;
vendor-specific component frameworks tend to involve a steeper learning curve.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	If
the access to a Java handle fails, an exception is thrown. This test
doesn&#8217;t have to occur right before the use of a handle; the Java
specification just says that the exception must somehow be thrown. Many C++
runtime systems can also throw exceptions for bad pointers.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Generally,
Java is more robust, via:
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Object handles initialized to 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>null</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
(a keyword)
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Handles are always checked and exceptions are thrown for failures
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
All array accesses are checked for bounds violations
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Automatic garbage collection prevents memory leaks
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Clean, relatively fool-proof exception handling
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Simple language support for multithreading
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">&#8211;
Bytecode verification of network applets
</FONT></OL><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Da Vinci Extras" SIZE=39 COLOR="Black">K</FONT><a name="_Toc407441464"></a><a name="_Toc408018848"></a><P></DIV>

<div align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0197.html">Prev</a> | <a href="tij0199.html">Next</a>
</div>
</body></html>