tij320.htm

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

inner classes</b>. The use of inner classes will not uncouple the classes, but
rather make the coupling explicit and more convenient. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2880" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Don&#146;t fall prey to premature optimization</b>. This way lies
madness. In particular, don&#146;t worry about writing (or avoiding) native
methods, making some methods <b>final</b>, or tweaking code to be efficient when
you are first constructing the system. Your primary goal should be to prove the
design. Even if the design requires a certain efficiency, <i>first make it work,
then make it fast</i>. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2881" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Keep scopes as small as possible so the visibility and lifetime of your
objects are as small as possible</b>. This reduces the chance of using an object
in the wrong context and hiding a difficult-to-find bug. For example, suppose
you have a container and a piece of code that iterates through it. If you copy
that code to use with a new container, you may accidentally end up using the
size of the old container as the upper bound of the new one. If, however, the
old container is out of scope, the error will be caught at compile time. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2882"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Use the containers in the standard Java library</b>. Become proficient
with their use and you&#146;ll greatly increase your productivity. Prefer
<b>ArrayList</b> for sequences, <b>HashSet</b> for sets, <b>HashMap</b> for
associative arrays, and <b>LinkedList</b> for stacks (rather than <b>Stack</b>,
although you may want to create an adapter to give a stack interface) and queues
(which may also warrant an adapter, as shown in this book). When you use the
first three, you should upcast to <b>List</b>, <b>Set</b>, and <b>Map</b>,
respectively, so that you can easily change to a different implementation if
necessary. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2883" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>For a program to be robust, each component must be robust</b>. Use all
the tools provided by Java&#151;access control, exceptions, type checking,
synchronization, and so on&#151;in each class you create. That way you can
safely move to the next level of abstraction when building your system. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2884"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Prefer compile-time errors to run-time errors</b>. Try to handle an error
as close to the point of its occurrence as possible. Catch any exceptions in the
nearest handler that has enough information to deal with them. Do what you can
with the exception at the current level; if that doesn&#146;t solve the
problem, rethrow the exception. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2885" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><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.) <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2886" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Keep things as &#147;<i>private</i> as possible</b>.<b>&#148;</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&#146;ll wreck somebody&#146;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&#151;only <b>private</b> fields can be protected against
un-<b>synchronized</b> use. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2887" title="Send BackTalk
Comment">Feedback</a></font><br>Classes with package access should still have
<b>private</b> fields, but it usually makes sense to give the methods of package
access rather than making them <b>public</b>. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]A0464" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><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 some comments. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2888" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Avoid using &#147;magic numbers&#148;</b>&#151;which are numbers
hard-wired into code. These are a nightmare if you need to change them, since
you never know if &#147;100&#148; means &#147;the array size&#148; or
&#147;something else entirely.&#148; 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. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2889"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>When creating constructors, consider exceptions</b>. In the best case,
the constructor won&#146;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&#146;t continue blindly, thinking that the object was created correctly.
<font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2890"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><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), because 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.
<font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2897"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><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>dispose(&#160;)</b> that clearly suggests its purpose. In
addition, place a <b>boolean</b> flag in the class to indicate whether
<b>dispose(&#160;)</b> has been called so that <b>finalize(&#160;)</b> can check
for &#147;the termination condition&#148; (see Chapter 4). <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2891" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>The responsibility of <i>finalize(&#160;)</i> can only be to verify
&#147;the termination condition&#148; 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(&#160;) </b>to
perform necessary cleanup. For that you must create your own
<b>dispose(&#160;)</b> method. In the <b>finalize(&#160;)</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&#146;t, to indicate a
programming error. Before relying on such a scheme, ensure that
<b>finalize(&#160;) </b>works on your system. (You might need to call
<b>System.gc(&#160;)</b> to ensure this behavior.) <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2892" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>If an object must be cleaned up (other than by garbage collection) within
a particular scope, use the following idiom:</b> initialize the object and, if
successful, immediately enter a <b>try</b> block with a <b>finally</b> clause
that performs the cleanup. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2893" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>When overriding <i>finalize(&#160;)</i> during inheritance, remember to
call <i>super.finalize(&#160;)</i></b>. (This is not necessary if <b>Object</b>
is your immediate superclass.) You should call <b>super.finalize(&#160;)</b> as
the <i>final</i> act of your overridden <b>finalize(&#160;)</b> rather than the
first, to ensure that base-class components are still valid if you need them.
<font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2894"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>When you are creating a fixed-size container of objects, transfer them to
an array</b>, especially if you&#146;re returning this container from a method.
This way you get the benefit of the array&#146;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(&#160;)</b> methods to
accomplish this. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2895" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><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&#146;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. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2896" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><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. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2898" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Watch out for accidental overloading</b>. If you attempt to override a
base-class method and you don&#146;t quite get the spelling right, you&#146;ll
end up adding a new method rather than overriding an existing method. However,
this is perfectly legal, so you won&#146;t get any error message from the
compiler or run-time system; your code simply won&#146;t work correctly. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2899"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Watch out for premature optimization</b>. First make it work, then make
it fast&#151;but only if you must, and only if it&#146;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 extra cost of performance tweaks is that your code becomes less
understandable and maintainable. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2900" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><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, tests, 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 JDK documentation should convince you.
<font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2901"
title="Send BackTalk
Comment">Feedback</a></font></li></ol><p class="Numbered"><br></p>
<hr><p class="footnote text"><sup><a name="fn122" href="#fnB122">[122]</a></sup> Explained to me by Andrew Koenig.<br></p>

<!-- <hr><b>Placeholder</b> -->

<hr>

<div align="CENTER"><a href="TIJ319.htm" target="RightFrame"><img src="./prev.gif" alt="Previous " border="0"></a>
<a href="TIJ321.htm" target="RightFrame"><img src="./next.gif" alt="Next " border="0"></a>

<a href="TIJ3_t.htm"><img src="./first.gif" alt="Title Page " border="0"></a>
<a href="TIJ3_i.htm"><img src="./index.gif" alt="Index " border="0"></a>
<a href="TIJ3_c.htm"><img src="./contents.gif" alt="Contents " border="0"></a>
</div>

</font></body>

</html>