📄 appendc.htm
字号:
<!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:TIJ2.rtf
Application Directory:C:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:05/21/2001
Translation Time:10:39:35
Translation Platform:Win32
Number of Output files:23
This File:AppendC.htm
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.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README.txt">Viewing Hints</a> ]
[ <a href="RevHist.htm">Revision History</a> ]
[ <a href="http://www.mindview.net/Books/TIJ/">Book Home Page</a> ]
[ <a href="http://www.mindview.net/Etc/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Seminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CDs">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/Services">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 2nd edition, Revision 12</FONT></H2>
<H3><FONT FACE="Verdana">©2000 by Bruce Eckel</FONT></H3>
<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>
</CENTER>
</P></DIV><A NAME="Appendix_B"></A><A NAME="Appendix_C"></A><A NAME="_Toc375545509"></A><A NAME="_Toc477690738"></A><A NAME="_Toc481064959"></A><A NAME="Heading640"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
C: Java Programming Guidelines</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia" SIZE=4><backtalk:display ID=TIJ3_APPENDIXC_I0>
This
appendix contains suggestions to help guide you in performing low-level program
design, and in writing
<A NAME="Index2294"></A><A NAME="Index2295"></A><A NAME="Index2296"></A><A NAME="Index2297"></A>code.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Naturally, these are guidelines and not
rules. The idea is to use them as inspirations, and to remember that there are
occasional situations where you need to bend or break a rule.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I0'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I1>
</FONT><A NAME="_Toc481064960"></A><BR></P></DIV>
<A NAME="Heading641"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Design</H2></FONT>
<OL>
<LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Elegance always
pays off</B>. 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). Not
only does it give you a program that’s easier to build and debug, but
it’s also easier to understand and maintain, and that’s where the
financial value lies. This point can take some experience to understand, because
it can appear that you’re not being productive while you’re making a
piece of code elegant. Resist the urge to hurry; it will only slow you down.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I1'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I2>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>First
make it work, then make it fast</B>. This is true even if you are certain that a
piece of code is really important and that it will be a principal bottleneck in
your system. Don’t do it. Get the system going first with as simple a
design as possible. Then if it isn’t going fast enough, profile it.
You’ll almost always discover that “your” bottleneck
isn’t the problem. Save your time for the really important stuff.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I2'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I3>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Remember
the “divide and conquer” principle</B>. If the problem you’re
looking at is too confusing, try to imagine what the basic operation of the
program would be, given the existence of a magic “piece” that
handles the hard parts. That “piece” is an object—write the
code that uses the object, then look at the object and encapsulate <I>its</I>
hard parts into other objects, etc.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I3'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I4>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Separate
the class creator from the class user (<I>client programmer</I>)</B>. The class
user is the “customer” and doesn’t need or want to know
what’s going on behind the scenes of the class. The class creator must be
the expert in class design and write the class so that it can be used by the
most novice programmer possible, yet still work robustly in the application.
Library use will be easy only if it’s transparent.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I4'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I5>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>When
you create a class, attempt to make your names so clear that comments are
unnecessary</B>. Your goal should be to make the client programmer’s
interface conceptually simple. To this end, use method overloading when
appropriate to create an intuitive, easy-to-use interface.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I5'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I6>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Your
analysis and design must produce, at minimum, the classes in your system, their
public interfaces, and their relationships to other classes, especially base
classes</B>. If your design methodology produces more than that, ask yourself if
all the pieces produced by that methodology have value over the lifetime of the
program. If they do not, maintaining them will cost you. Members of development
teams tend not to maintain anything that does not contribute to their
productivity; this is a fact of life that many design methods don’t
account for.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I6'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I7>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Automate
everything</B>.<B> </B>Write the test code first (before you write the class),
and keep it with the class. Automate the running of your tests through a
makefile or similar tool. This way, any changes can be automatically verified by
running the test code, and you’ll immediately discover errors. Because you
know that you have the safety net of your test framework, you will be bolder
about making sweeping changes when you discover the need. Remember that the
greatest improvements in languages come from the built-in testing provided by
type checking, exception handling, etc., but those features take you only so
far. You must go the rest of the way in creating a robust system by filling in
the tests that verify features that are specific to your class or program.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I7'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I8>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Write
the test code first (before you write the class) in order to verify that your
class design is complete</B>. If you can’t write test code, you
don’t know what your class looks like. In addition, the act of writing the
test code will often flush out additional features or constraints that you need
in the class—these features or constraints don’t always appear
during analysis and design. Tests also provide example code showing how your
class can be used.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I8'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I9>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>All
software design problems can be simplified by introducing an extra level of
conceptual indirection</B><I>.</I> This fundamental rule of software
engineering</FONT><A NAME="fnB85" HREF="#fn85">[85]</A><A NAME="Index2298"></A><FONT FACE="Georgia">
is the basis of abstraction, the primary feature of object-oriented programming.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I9'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I10>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>An
indirection should have a meaning </B>(in concert with guideline 9). This
meaning can be something as simple as “putting commonly used code in a
single method.” If you add levels of indirection (abstraction,
encapsulation, etc.) that don’t have meaning, it can be as bad as not
having adequate indirection.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I10'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I11>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Make
classes as atomic as possible</B>. Give each class a single, clear purpose. If
your classes or your system design grows too complicated, break complex classes
into simpler ones. The most obvious indicator of this is sheer size: if a class
is big, chances are it’s doing too much and should be broken
up.</FONT><BR><FONT FACE="Georgia">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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I11'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I12>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
for long argument lists</B>. Method calls then become difficult to write, read,
and maintain. Instead, try to move the method to a class where it is (more)
appropriate, and/or pass objects in as arguments.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I12'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I13>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Don’t
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -