tij320.htm

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

overloaded methods instead. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2855" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Use exception hierarchies</b>&#151;preferably derived from specific
appropriate classes in the standard Java exception hierarchy. The person
catching the exceptions can then write handlers for the specific types of
exceptions, followed by handlers for the base type. If you add new derived
exceptions, existing client code will still catch the exception through the base
type. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2856" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Sometimes simple aggregation does the job</b>. A &#147;passenger comfort
system&#148; on an airline consists of disconnected elements: seat, air
conditioning, video, etc., and yet you need to create many of these in a plane.
Do you make private members and build a whole new interface? No&#151;in this
case, the components are also part of the public interface, so you should create
public member objects. Those objects have their own private implementations,
which are still safe. Be aware that simple aggregation is not a solution to be
used often, but it does happen. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2857" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Consider the perspective of the client programmer and the person
maintaining the code</b>. Design your class to be as obvious as possible to use.
Anticipate the kind of changes that will be made, and design your class so that
those changes will be easy. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2858" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Watch out for &#147;giant object syndrome.&#148;</b> This is often an
affliction of procedural programmers who are new to OOP and who end up writing a
procedural program and sticking it inside one or two giant objects. With the
exception of application frameworks, objects represent concepts in your
application, not the application itself. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2859" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>If you must do something ugly, at least localize the ugliness inside a
class</b>. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2860" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>If you must do something nonportable, make an abstraction for that
service and localize it within a class</b>. This extra level of indirection
prevents the nonportability from being distributed throughout your program.
(This idiom is embodied in the <i>Bridge </i>Pattern, among others). <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2861"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Objects should not simply hold some data</b>. They should also have
well-defined behaviors. (Occasionally, &#147;data objects&#148; are
appropriate, but only when used expressly to package and transport a group of
items when a generalized container is innappropriate.) <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2862" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Choose composition first when creating new classes from existing
classes</b>. You should only use inheritance if it is required by your design.
If you use inheritance where composition will work, your designs will become
needlessly complicated. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2863" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Use inheritance and method overriding to express differences in behavior,
and fields to express variations in state</b>. An extreme example of what not to
do is to inherit different classes to represent colors instead of using a
&#147;color&#148; field. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2864" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Watch out for <i>variance</i></b>. Two semantically different objects may
have identical actions, or responsibilities, and there is a natural temptation
to try to make one a subclass of the other just to benefit from inheritance.
This is called variance, but there&#146;s no real justification to force a
superclass/subclass relationship where it doesn&#146;t exist. A better solution
is to create a general base class that produces an interface for both as derived
classes; it requires a bit more space, but you still benefit from inheritance
and will probably make an important discovery about the design. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2865"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Watch out for <i>limitation</i> during inheritance</b>. The clearest
designs add new capabilities to inherited ones. A suspicious design removes old
capabilities during inheritance without adding new ones. But rules are made to
be broken, and if you are working from an old class library, it may be more
efficient to restrict an existing class in its subclass than it would be to
restructure the hierarchy so your new class fits in where it should, above the
old class. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2866" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Use design patterns to eliminate &#147;naked functionality.&#148;</b>
That is, if only one object of your class should be created, don&#146;t bolt
ahead to the application and write a comment &#147;Make only one of
these.&#148; 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
&#147;naked functionality&#148; will not only make your code much easier to
understand and maintain, but it will also make it more bulletproof against the
well-intentioned maintainers that come after you. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2867" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Watch out for &#147;analysis paralysis.&#148;</b> 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. You
can&#146;t know the solution until you <i>have</i> the solution. Java has
built-in firewalls; let them work for you. Your mistakes in a class or set of
classes won&#146;t destroy the integrity of the whole system. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2868"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>When you think you&#146;ve got a good analysis, design, or
implementation, do a walkthrough</b>. Bring someone in from outside your
group&#151;this doesn&#146;t have to be a consultant, but can be someone from
another group within your company. Reviewing your work with a fresh pair of eyes
can reveal problems at a stage when it&#146;s much easier to fix them, and more
than pays for the time and money &#147;lost&#148; to the walkthrough process.
<font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2869"
title="Send BackTalk Comment">Feedback</a></font></li></ol><h2>
<a name="_Toc24776014"></a><a name="Heading25795"></a>Implementation</h2>
<ol>
<li><b>In general, follow the Sun coding conventions</b>. These are available
at<br><i>java.sun.com/docs/codeconv/index.html</i> (the code in this book
follows these conventions as much as I was able). These are used for what
constitutes arguably the largest body of code that the largest number of Java
programmers will be exposed to. If you doggedly stick to the coding style
you&#146;ve always used, you will make it harder for your reader. Whatever
coding conventions you decide on, ensure that they are consistent throughout the
project. There is a free tool to automatically reformat Java code at
<i>http://jalopy.sourceforge.net.</i> You can find a free style checker at
<i>http://jcsc.sourceforge.net</i>. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2870" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Whatever coding style you use, it really does make a difference if your
team (and even better, your company) standardizes on it</b>. This means to the
point that everyone considers it fair game to fix someone else&#146;s coding
style if it doesn&#146;t conform. The value of standardization is that it takes
less brain cycles to parse the code, so that you can focus more on what the code
means. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2871" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Follow standard capitalization rules</b>. Capitalize the first letter of
class names. The first letter of fields, methods, and objects (references)
should be lowercase. All identifiers should run their words together, and
capitalize the first letter of all intermediate words. For
example:<br><b>ThisIsAClassName</b><br><b>thisIsAMethodOrFieldName</b><br>Capitalize
<i>all</i> the letters (and use underscore word separators) of <b>static</b>
<b>final</b> primitive identifiers that have constant initializers in their
definitions. This indicates that they are compile-time constants.<br><b>Packages
are a special case</b>&#151;they are all lowercase letters, even for
intermediate words. The domain extension (com, org, net, edu, etc.) should also
be lowercase. (This was a change between Java 1.1 and Java 2.) <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2872"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Don&#146;t create your own &#147;decorated&#148; private field
names</b>. This is usually seen in the form of prepended underscores and
characters. Hungarian notation is the worst example of this, where you attach
extra characters that indicate data type, use, location, etc., as if you were
writing assembly language and the compiler provided no extra assistance at all.
These notations are confusing, difficult to read, and unpleasant to enforce and
maintain. Let classes and packages do the name scoping for you. If you feel that
you must decorate your names to prevent confusion, your code is probably too
confusing anyway and should be simplified. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2873" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Follow a &#147;canonical form&#148; </b>when creating a class for
general-purpose use. Include definitions for <b>equals(&#160;)</b>,
<b>hashCode(&#160;)</b>, <b>toString(&#160;)</b>, <b>clone(&#160;)</b>
(implement <b>Cloneable</b>, or choose some other object copying approach, like
serialization), and implement <b>Comparable </b>and <b>Serializable</b>. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2874"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>Use the JavaBeans &#147;get,&#148; &#147;set,&#148; and
&#147;is&#148; naming conventions</b> for methods that read and change
<b>private</b> fields, even if you don&#146;t think you&#146;re making a
JavaBean at the time. Not only does it make it easy to use your class as a Bean,
but it&#146;s a standard way to name these kinds of methods, so it will be more
easily understood by the reader. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2875" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>For each class you create, include JUnit tests for that class</b> (see
<i>www.junit.org</i>, and examples in Chapter 15). You don&#146;t need to
remove the test code to use the class in a project, and if you make any changes,
you can easily rerun the tests. This code also provides examples of how to use
your class. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2876" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Sometimes you need to inherit in order to access <i>protected</i> members
of the base class</b>. This can lead to a perceived need for multiple base
types. If you don&#146;t need to upcast, first derive a new class to perform
the protected access. Then make that new class a member object inside any class
that needs to use it, rather than inheriting. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2877" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Avoid the use of <i>final</i> methods for efficiency purposes</b>. Use
<b>final </b>only when the program is running, but not fast enough, and your
profiler has shown you that a method invocation is the bottleneck. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2878"
title="Send BackTalk Comment">Feedback</a></font></li>
<li><b>If two classes are associated with each other in some functional way
(such as containers and iterators), try to make one an inner class of the
other</b>. This not only emphasizes the association between the classes, but it
allows the class name to be reused within a single package by nesting it within
another class. The Java containers library does this by defining an inner
<b>Iterator</b> class inside each container class, thereby providing the
containers with a common interface. The other reason you&#146;ll want to use an
inner class is as part of the <b>private </b>implementation. Here, the inner
class is beneficial for implementation hiding rather than the class association
and prevention of namespace pollution noted above. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]AppendC_2879" title="Send BackTalk
Comment">Feedback</a></font></li>
<li><b>Anytime you notice classes that appear to have high coupling with each
other, consider the coding and maintenance improvements you might get by using