📄 appendixc.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:Tjava14.rtf
Application Directory:c:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:02/04/2000
Translation Time:23:26:29
Translation Platform:Win32
Number of Output files:27
This File:AppendixC.html
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>C: Java programming guidelines</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview-head.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README-HTML.txt">Viewing Hints</a> ]
[ <a href="http://www.mindview.net/TIJ2/index.html">2nd Edition</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Training.html">Seminars</a> ]
[ <a href="http://www.mindview.net/javaCD2.html">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 1st edition</FONT></H2>
<H3><FONT FACE="Verdana">©1998 by Bruce Eckel</FONT></H3>
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendixB.html">Previous Chapter</a> ]
[ <a href="SimpleContents.html">Short TOC</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="AppendixD.html">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc407441464"></A><A NAME="_Toc408018848"></A><A NAME="Heading632"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
C: Java programming guidelines</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>This appendix contains
suggestions to help guide you while performing low-level program design, and
also while writing
<A NAME="Index3116"></A><A NAME="Index3117"></A><A NAME="Index3118"></A><A NAME="Index3119"></A>code.</FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Georgia"> Capitalize the first letter of class names. The
first letter of fields, methods, and objects (handles) should be lowercase. All
identifiers should run their words together, and capitalize the first letter of
all intermediate words. For
example:</FONT><BR><FONT FACE="Georgia"><B>ThisIsAClassName</B></FONT><BR><FONT FACE="Georgia"><B>thisIsAMethodOrFieldName</B></FONT><BR><FONT FACE="Georgia">Capitalize
<I>all</I> the letters of <B>static</B> <B>final</B> primitive identifiers that
have constant initializers in their definitions. This indicates they are
compile-time constants.</FONT><BR><FONT FACE="Georgia">Packages are a
special case: 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
1.2.)</FONT><LI><FONT FACE="Georgia"> When creating a class for
general-purpose use, follow a “canonical form” and include
definitions for <B>equals( )</B>, <B>hashCode( )</B>,
<B>toString( )</B>, <B>clone( )</B> (implement <B>Cloneable</B>), and
implement <B>Serializable</B>. </FONT><LI><FONT FACE="Georgia"> For each
class you create, consider including a <B>main( )</B> that contains code to
test that class. You don’t need to remove the test code to use the class
in a project, and if you make any changes you can easily re-run the tests. This
code also provides examples of how to use your
class.</FONT><LI><FONT FACE="Georgia"> Methods should be kept to brief,
functional units that describe and implement a discrete part of a class
interface. Ideally, methods should be concise; if they are long you might want
to search for a way to break them up into several shorter methods. This will
also foster reuse within your class. (Sometimes methods must be large, but they
should still do just one thing.)</FONT><LI><FONT FACE="Georgia"> When you
design a class, think about the client programmer’s perspective (the class
should be fairly obvious to use) and the perspective of the person maintaining
the code (anticipate the kind of changes that will be made, to make them
easy).</FONT><LI><FONT FACE="Georgia"> Try to keep classes small and
focused. Clues to suggest redesign of a class
are:</FONT><BR><FONT FACE="Georgia">1) A complicated switch statement:
consider using polymorphism </FONT><BR><FONT FACE="Georgia">2) A large
number of methods that cover broadly different types of operations: consider
using several classes</FONT><BR><FONT FACE="Georgia">3) A large number of
member variables that concern broadly different characteristics: consider using
several classes</FONT><LI><FONT FACE="Georgia"> Keep things as
“<B>private</B> as possible.” 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.
Privacy is especially important when dealing with multithreading – only
<B>private</B> fields can be protected against un-<B>synchronized</B>
use.</FONT><LI><FONT FACE="Georgia"> Watch out for “giant object
syndrome.” 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.</FONT><LI><FONT FACE="Georgia"> If you must do something
ugly, at least localize the ugliness inside a
class.</FONT><LI><FONT FACE="Georgia"> Anytime you notice classes that
appear to have high coupling with each other, consider the coding and
maintenance improvements you might get by using inner classes (see
“<A HREF="Chapter14.html#_Ref403700451">Improving the code with an inner class</A>”
on page 701).</FONT><LI><FONT FACE="Georgia"> Use comments liberally, and
use the <B>javadoc </B>comment-documentation syntax to produce your program
documentation.</FONT><LI><FONT FACE="Georgia"> Avoid using “magic
numbers,” 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.</FONT><LI><FONT FACE="Georgia"> In terms of
constructors and exceptions, you’ll generally want to re-throw any
exceptions that you catch while in a constructor if it causes failure of the
creation of that object, so the caller doesn’t continue blindly, thinking
that the object was created correctly.</FONT><LI><FONT FACE="Georgia"> 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 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. 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.runFinalizersOnExit(true)</B> to
ensure this behavior.)</FONT><LI><FONT FACE="Georgia"> 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 <B>try</B> block with a <B>finally</B> clause that performs the
cleanup.</FONT><LI><FONT FACE="Georgia"> When overriding
<B>finalize( )</B> during inheritance, remember to call
<B>super.finalize( )</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.</FONT><LI><FONT FACE="Georgia"> When you are creating a fixed-size
collection of objects, transfer them to an array (especially if you’re
returning this collection 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.</FONT><LI><FONT FACE="Georgia"> Choose <B>interface</B>s over
<B>abstract</B> classes. 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.</FONT><LI><FONT FACE="Georgia"> Inside constructors, do only what
is necessary to set the object into the proper state. 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.)</FONT><LI><FONT FACE="Georgia"> Objects
should not simply hold some data; they should also have well-defined
behaviors.</FONT><LI><FONT FACE="Georgia"> 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="Georgia"> 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 “color”
field.</FONT><LI><FONT FACE="Georgia"> To avoid a highly frustrating
experience, make sure that there’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 <B>.class</B> files with the
same names at each of the starting points in your
classpath.</FONT><LI><FONT FACE="Georgia"> When using the event
“adapters” in the Java 1.1 AWT, there’s a particularly easy
pitfall you can encounter. If you override one of the adapter methods 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.</FONT><LI><FONT FACE="Georgia"> Use design patterns to
eliminate “naked functionality.” That is, if only one object of your
class should be created, don’t bolt ahead to the application and write a
comment “Make only one of these.” 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 “naked functionality” 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="Georgia"> Watch out for “analysis
paralysis.” 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="Georgia"> Watch out
for premature optimization. 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. </FONT><LI><FONT FACE="Georgia"> 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="Georgia"> When
you think you’ve got a good analysis, design, or implementation, do a
walkthrough. Bring someone in from outside your group – this doesn’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’s much easier to fix them and more than pays for the time
and money “lost” to the walkthrough
process.</FONT><LI><FONT FACE="Georgia"> 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’ll see the rewards (even if no one can measure them). And
there’s nothing that matches the feeling that comes from knowing
you’ve got an amazing design. Resist the urge to hurry; it will only slow
you down.</FONT><LI><FONT FACE="Georgia"> You can find other programming
guidelines on the Web. A good set of links can be found at
</FONT><BR><FONT FACE="Georgia"><I>http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio.html</I>
</FONT></OL>
<DIV ALIGN="CENTER">
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendixB.html">Previous Chapter</a> ]
[ <a href="SimpleContents.html">Short TOC</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="AppendixD.html">Next Chapter</a> ]
</FONT>
<BR>
Last Update:02/04/2000</P></DIV>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -