tij0199.html

学习java的经典书籍

on your system. (You might need to call 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>System.runFinalizersOnExit(true)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
to ensure this behavior.)
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	If
an object must be cleaned up (other than by garbage collection) within a
particular scope, use the following approach: Initialize the object and, if
successful, immediately enter a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>try</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
block with 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 that performs the cleanup.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	When
overriding 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
during inheritance, remember to call 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>super.finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
(this is not necessary if 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Object</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
is your immediate superclass). You should call 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>super.finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
as the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>final</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
act of your overridden 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
rather than the first, to ensure that base-class components are still valid if
you need them.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	When
you are creating a fixed-size collection of objects, transfer them to an array
(especially if you&#8217;re returning this collection from a method). This way
you get the benefit of the array&#8217;s compile-time type checking, and the
recipient of the array might not need to cast the objects in the array in order
to use them.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Choose
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">s
over 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>abstract</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
classes. If you know something is going to be a base class, your first choice
should be to make it an 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
and only if you&#8217;re forced to have method definitions or member variables
should you change it to an 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>abstract</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
class. An 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">talks
about what the client wants to do, while a class tends to focus on (or allow)
implementation details.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Inside
constructors, do only what is necessary to set the object into the proper
state. Actively avoid calling other methods (except for 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>final</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
methods) since those methods can be overridden by someone else to produce
unexpected results during construction. (See Chapter 7 for details.)
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Objects
should not simply hold some data; they should also have well-defined behaviors.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Choose
composition first when creating new classes from existing classes. You should
only used inheritance if it is required by your design. If you use inheritance
where composition will work, your designs will become needlessly complicated.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Use
inheritance and method overriding to express differences in behavior, and
fields to express variations in state. An extreme example of what not to do is
inheriting different classes to represent colors instead of using a
&#8220;color&#8221; field.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	To
avoid a highly frustrating experience, make sure that there&#8217;s only one
class of each name anywhere in your classpath. Otherwise, the compiler can find
the identically-named other class first, and report error messages that make no
sense. If you suspect that you are having a classpath problem, try looking for 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>.class</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
files with the same names at each of the starting points in your classpath.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	When
using the event &#8220;adapters&#8221; in the Java 1.1<A NAME="Index3135"></A>
AWT, there&#8217;s a particularly easy pitfall you can encounter. If you
override one of the adapter methods and you don&#8217;t quite get the spelling
right, you&#8217;ll end up adding a new method rather than overriding an
existing method. However, this is perfectly legal, so you won&#8217;t get any
error message from the compiler or run-time system &#8211; your code simply
won&#8217;t work correctly.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Use
design patterns to eliminate &#8220;naked functionality.&#8221; That is, if
only one object of your class should be created, don&#8217;t bolt ahead to the
application and write a comment &#8220;Make only one of these.&#8221; Wrap it
in a singleton. If you have a lot of messy code in your main program that
creates your objects, look for a creational pattern like a factory method in
which you can encapsulate that creation. Eliminating &#8220;naked
functionality&#8221; will not only make your code much easier to understand and
maintain, it will also make it more bulletproof against the well-intentioned
maintainers that come after you.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Watch
out for &#8220;analysis paralysis.&#8221; Remember that you must usually move
forward in a project before you know everything, and that often the best and
fastest way to learn about some of your unknown factors is to go to the next
step rather than trying to figure it out in your head.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Watch
out for premature optimization. First make it work, then make it fast &#8211;
but only if you must, and only if it&#8217;s proven that there is a performance
bottleneck in a particular section of your code. Unless you have used a
profiler to discover a bottleneck, you will probably be wasting your time. The
hidden cost of performance tweaks is that your code becomes less understandable
and maintainable. 
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Remember
that code is read much more than it is written. Clean designs make for
easy-to-understand programs, but comments, detailed explanations, and examples
are invaluable. They will help both you and everyone who comes after you. If
nothing else, the frustration of trying to ferret out useful information from
the online Java documentation should convince you.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	When
you think you&#8217;ve got a good analysis, design, or implementation, do a
walkthrough. Bring someone in from outside your group &#8211; this
doesn&#8217;t have to be a consultant, but can be someone from another group
within your company. Reviewing your work with a pair of fresh eyes can reveal
problems at a stage where it&#8217;s much easier to fix them and more than pays
for the time and money &#8220;lost&#8221; to the walkthrough process.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	Elegance
always pays off. In the short term it might seem like it takes much longer to
come up with a truly graceful solution to a problem, but when it works the
first time and easily adapts to new situations instead of requiring hours,
days, or months of struggle, you&#8217;ll see the rewards (even if no one can
measure them). And there&#8217;s nothing that matches the feeling that comes
from knowing you&#8217;ve got an amazing design. Resist the urge to hurry; it
will only slow you down.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">	You
can find other programming guidelines on the Web. A good set of links can be
found at 
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio.html</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
</FONT></OL><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Da Vinci Extras" SIZE=47 COLOR="Black">8</FONT><a name="_Toc407441465"></a><a name="_Toc408018849"></a><P></DIV>

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