?? appendc.htm
字號:
has enough information to deal with them. Do what you can with the exception at
the current level; if that doesn’t solve the problem, rethrow the
exception.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I51'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I52>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
for long method definitions</B>. Methods should be brief, functional units that
describe and implement a discrete part of a class interface. A method that is
long and complicated is difficult and expensive to maintain, and is probably
trying to do too much all by itself. If you see such a method, it indicates
that, at the least, it should be broken up into multiple methods. It may also
suggest the creation of a new class. Small methods will also foster reuse within
your class. (Sometimes methods must be large, but they should still do just one
thing.)
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I52'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I53>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Keep
things as “<I>private</I> as possible.”</B> Once you publicize an
aspect of your library (a method, a class, a field), you can never take it out.
If you do, you’ll wreck somebody’s existing code, forcing them to
rewrite and redesign. If you publicize only what you must, you can change
everything else with impunity, and since designs tend to evolve this is an
important freedom. In this way, implementation changes will have minimal impact
on derived classes. Privacy is especially important when dealing with
multithreading—only <B>private</B> fields can be protected against
un-<B>synchronized</B> use.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I53'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I54>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Use
comments liberally, and use the <I>javadoc</I> comment-documentation syntax to
produce your program documentation</B>. However, the comments should add geniune
meaning to the code; comments that only reiterate what the code is clearly
expressing are annoying. Note that the typical verbose detail of Java class and
method names reduce the need for as many comments.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I54'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I55>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Avoid
using “magic numbers”</B>—which are numbers hard-wired into
code. These are a nightmare if you need to change them, since you never know if
“100” means “the array size” or “something else
entirely.” Instead, create a constant with a descriptive name and use the
constant identifier throughout your program. This makes the program easier to
understand and much easier to maintain.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I55'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I56>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>When
creating constructors, consider exceptions</B>. In the best case, the
constructor won’t do anything that throws an exception. In the next-best
scenario, the class will be composed and inherited from robust classes only, so
they will need no cleanup if an exception is thrown. Otherwise, you must clean
up composed classes inside a <B>finally</B> clause. If a constructor must fail,
the appropriate action is to throw an exception, so the caller doesn’t
continue blindly, thinking that the object was created correctly.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I56'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I57>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>If
your class requires any cleanup when the client programmer is finished with the
object, place the cleanup code in a single, well-defined method</B>—with a
name like <B>cleanup( )</B> that clearly suggests its purpose. In addition,
place a <B>boolean</B> flag in the class to indicate whether the object has been
cleaned up so that <B>finalize( )</B> can check for “the death
condition” (see Chapter 4).
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I57'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I58>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>The
responsibility of <I>finalize( )</I> can only be to verify “the death
condition” of an object for debugging.</B> (See Chapter 4.) In special
cases, it might be needed to release memory that would not otherwise be released
by the garbage collector. Since the garbage collector might not get called for
your object, you cannot use <B>finalize( ) </B>to perform necessary
cleanup. For that you must create your own “cleanup” method. In the
<B>finalize( )</B> method for the class, check to make sure that the object
has been cleaned up and throw a class derived from <B>RuntimeException</B> if it
hasn’t, to indicate a programming error. Before relying on such a scheme,
ensure that <B>finalize( ) </B>works on your system. (You might need to
call <B>System.gc( )</B> to ensure this behavior.)
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I58'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I59>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>If
an object must be cleaned up (other than by garbage collection) within a
particular scope, use the following approach:</B> Initialize the object and, if
successful, immediately enter a <B>try</B> block with a <B>finally</B> clause
that performs the cleanup.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I59'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I60>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>When
overriding <I>finalize( )</I> during inheritance, remember to call
<I>super.finalize( )</I>.</B> (This is not necessary if <B>Object</B> is
your immediate superclass.) You should call <B>super.finalize( )</B> as the
<I>final</I> act of your overridden <B>finalize( )</B> rather than the
first, to ensure that base-class components are still valid if you need them.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I60'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I61>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>When
you are creating a fixed-size container of objects, transfer them to an
array</B>—especially if you’re returning this container from a
method. This way you get the benefit of the array’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. Note that the base-class of the containers
library, <B>java.util.Collection</B>, has two <B>toArray( )</B> methods to
accomplish this.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I61'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I62>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Choose
<I>interfaces</I> over <I>abstract</I> classes</B>. If you know something is
going to be a base class, your first choice should be to make it an
<B>interface</B>, and only if you’re forced to have method definitions or
member variables should you change it to an <B>abstract</B> class. An
<B>interface </B>talks about what the client wants to do, while a class tends to
focus on (or allow) implementation details.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I62'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I63>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Inside
constructors, do only what is necessary to set the object into the proper
state</B>. Actively avoid calling other methods (except for <B>final</B>
methods) since those methods can be overridden by someone else to produce
unexpected results during construction. (See Chapter 7 for details.) Smaller,
simpler constructors are less likely to throw exceptions or cause problems.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I63'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I64>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>To
avoid a highly frustrating experience, make sure that there is only one
unpackaged class of each name anywhere in your classpath</B>. 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 <B>.class</B> files with the same names at each of the
starting points in your classpath. Ideally, put all your classes within
packages.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I64'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I65>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
out for accidental overloading</B>. If you attempt to override a base-class
method and you don’t quite get the spelling right, you’ll end up
adding a new method rather than overriding an existing method. However, this is
perfectly legal, so you won’t get any error message from the compiler or
run-time system—your code simply won’t work correctly.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I65'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I66>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
out for premature optimization</B>. First make it work, then make it
fast—but only if you must, and only if it’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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I66'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I67>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Remember
that code is read much more than it is written</B>. 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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I67'
target="_blank">Add Comment</a> ]
</FONT></OL>
<HR><DIV ALIGN="LEFT"><P><A NAME="fn85" HREF="#fnB85">[85]</A><FONT FACE="Georgia" SIZE=2>
Explained to me by Andrew Koenig.</FONT><BR></P></DIV>
<DIV ALIGN="CENTER">
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendB.htm">Previous Chapter</a> ]
[ <a href="SimpCont.htm">Short TOC</a> ]
[ <a href="Contents.htm">Table of Contents</a> ]
[ <a href="DocIdx.htm">Index</a> ]
[ <a href="AppendD.htm">Next Chapter</a> ]
</FONT>
<BR>
Last Update:05/21/2001</P></DIV>
</BODY>
</HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -