📄 tij0199.html
字号:
<html><body>
<table width="100%"><tr>
<td>
<a href="http://www.bruceeckel.com/javabook.html">Bruce Eckel's Thinking in Java</a>
</td>
<td align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0198.html">Prev</a> | <a href="tij0200.html">Next</a>
</td>
</tr></table>
<hr>
<H1 ALIGN=LEFT>
C:
Java programming guidelines
</H1>
<DIV ALIGN=LEFT><FONT FACE="Calligraph421 BT" SIZE=4 COLOR="Black">This
appendix contains suggestions to help guide you while performing low-level
program design, and also while writing <A NAME="Index3129"></A><A NAME="Index3130"></A><A NAME="Index3131"></A><A NAME="Index3132"></A>code.</FONT><P></DIV>
<OL>
<LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> 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><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>ThisIsAClassName</B></FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>thisIsAMethodOrFieldName</B></FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Capitalize
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>all</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
the letters of
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>static</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>final</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
primitive identifiers that have constant initializers in their definitions.
This indicates they are compile-time constants.
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">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<A NAME="Index3133"></A>
and Java 1.2.<A NAME="Index3134"></A>)</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> When
creating a class for general-purpose use, follow a “canonical form”
and include definitions for
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>equals( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>hashCode( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>toString( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>clone( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
(implement
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Cloneable</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">),
and implement
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Serializable</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> For
each class you create, consider including a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>main( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
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="Carmina Md BT" SIZE=3 COLOR="Black"> 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="Carmina Md BT" SIZE=3 COLOR="Black"> 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="Carmina Md BT" SIZE=3 COLOR="Black"> Try
to keep classes small and focused. Clues to suggest redesign of a class are:
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">1)
A complicated switch statement: consider using polymorphism
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">2)
A large number of methods that cover broadly different types of operations:
consider using several classes
</FONT><P><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">3)
A large number of member variables that concern broadly different
characteristics: consider using several classes
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> Keep
things as “
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>private</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
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
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>private</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
fields can be protected against un-
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>synchronized</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
use.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> 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="Carmina Md BT" SIZE=3 COLOR="Black"> If
you must do something ugly, at least localize the ugliness inside a class.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> 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="tij0155.htm#_Ref403700451">Improving
the code with an inner class
</A>”
on page
<A HREF=" PAGE#_Ref403700451">759</A>).</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> Use
comments liberally, and use the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>javadoc
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">comment-documentation
syntax to produce your program documentation.
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> 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="Carmina Md BT" SIZE=3 COLOR="Black"> 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="Carmina Md BT" SIZE=3 COLOR="Black"> 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
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>cleanup( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
that clearly suggests its purpose. In addition, place a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>boolean</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
flag in the class to indicate whether the object has been cleaned up. In the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method for the class, check to make sure that the object has been cleaned up
and throw a class derived from
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>RuntimeException</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
if it hasn’t, to indicate a programming error. Before relying on such a
scheme, ensure that
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize( )
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">works
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -