appendc.htm

Thinking in Java, 2nd edition

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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I33' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I34>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>Watch
out for &#8220;analysis paralysis.&#8221;</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&#8217;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&#8217;t
destroy the integrity of the whole system.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I34' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I35>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>When
you think you&#8217;ve got a good analysis, design, or implementation, do a
walkthrough</B>. Bring someone in from outside your group&#8212;this
doesn&#8217;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&#8217;s much easier to fix them, and more than pays
for the time and money &#8220;lost&#8221; to the walkthrough process.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I35' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I36>
</FONT><A NAME="_Toc481064961"></A></OL><A NAME="Heading642"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Implementation</H2></FONT>
<OL>
<LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>In general,
follow the Sun coding conventions</B>. These are available
at</FONT><BR><FONT FACE="Georgia"><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&#8217;ve always used, you will make it harder for your reader.
Whatever coding conventions you decide on, ensure they are consistent throughout
the project. There is a free tool to automatically reformat Java code at:
<I>home.wtal.de/software-solutions/jindent.</I>

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I36' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I37>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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&#8217;s coding style if it
doesn&#8217;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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I37' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I38>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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:</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"><B>Packages are a special
case</B>&#8212;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.)

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I38' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I39>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>Don&#8217;t
create your own &#8220;decorated&#8221; private data member 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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I39' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I40>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>Follow
a &#8220;canonical form&#8221; </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>), and
implement <B>Comparable </B>and <B>Serializable</B>. 

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I40' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I41>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>Use
the JavaBeans &#8220;get,&#8221; &#8220;set,&#8221; and &#8220;is&#8221; naming
conventions</B> for methods that read and change <B>private</B> fields, even if
you don&#8217;t think you&#8217;re making a JavaBean at the time. Not only does
it make it easy to use your class as a Bean, but it&#8217;s a standard way to
name these kinds of methods and so will be more easily understood by the reader.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I41' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I42>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>For
each class you create, consider including a <I>static public test(&#160;)</I>
that contains code to test that class</B>. You don&#8217;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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I42' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I43>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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&#8217;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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I43' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I44>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I44' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I45>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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&#8217;ll want to use an inner class is as part
of the <B>private </B>implementation. Here, the inner class beneficial for
implementation hiding rather than the class association and prevention of
namespace pollution noted above.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I45' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I46>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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 inner
classes</B>. The use of inner classes will not uncouple the classes, but rather
make the coupling explicit and more convenient.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I46' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I47>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>Don&#8217;t
fall prey to premature optimization</B>. This way lies madness. In particular,
don&#8217;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, unless
the design requires a certain efficiency.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I47' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I48>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I48' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I49>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>Use
the containers in the standard Java library</B>. Become proficient with their
use and you&#8217;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>) and queues.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I49' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I50>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><B>For
a program to be robust, each component must be robust</B>. Use all the tools
provided by Java: access control, exceptions, type checking, and so on, in each
class you create. That way you can safely move to the next level of abstraction
when building your system.

</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I50' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_APPENDIXC_I51>
</FONT><LI><FONT FACE="Verdana"><B>	</B></FONT><FONT FACE="Georgia"><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. Prefer dealing with the error at that
point to throwing an exception. Catch any exceptions in the nearest handler that