Item 29: Minimize the scope of local variables
The most powerful technique for minimizing the scope of a local variable is to declare it where it is first used.
Nearly every local variable declaration should contain an initializer.
Keep methods small and focused.
The for loop allows you to declareloop variables, limiting their scope to the exact region where they're needed. (This region consists of the body of the loop as well as the initialization, test, and update preceding the body.) Therefore prefer for loops to while loops.
for (Iterator i = c.iterator(); i.hasNext(); ) 
{
doSomething(i.next());
}for (int i = 0, n = expensiveComputation(); i < n; i++) { doSomething(i);}Item 30: Know and use the libraries
Suppose you want to generate random integers between 0 and some upper bound.
static Random rnd = new Random();// Common but flawed!static int random(int n) { return Math.abs(rnd.nextInt()) % n;}By using a standard library, you take advantage of the knowledge of the experts who wrote it and the experience of
those who used it before you.
Numerous features are added to the libraries in every major release, and it pays to keep abreast of these additions.
Every programmer should be familiar with the contents of java.lang, java.util, and, to a lesser extent, java.io.
In the 1.2 release, a Collections Framework was added to the java.util package. It should be part of every programmer's basic toolkit.
A third-party library worthy of note is Doug Lea's util.concurrent, which provides high-level concurrency utilities to simplify the task of multithreaded programming.
There are many additions to the libraries in the 1.4 release. Notable additions include the following:
鈥?java.util.regex鈥?A full-blown Perl-like regular expression facility.
鈥?java.util.prefs鈥?A facility for the persistent storage of user preferences and program configuration data.
鈥?java.nio鈥?A high-performance I/O facility, including scalable I/O (akin to the Unix poll call) and memory-mapped I/O (akin to the Unix mmap call).
鈥?java.util.LinkedHashSet, LinkedHashMap, IdentityHashMap鈥?New collection implementations.
Item 31: Avoid float and double if exact answers are required
The float and double types are particularly ill-suited for monetary calculations because it is impossible to represent 0.1 (or any other negative power of ten) as a float or double exactly.
For example, suppose you have a dollar in your pocket, and you see a shelf with a row of delicious candies priced at 10, 20, 30, and so forth, up to a dollar.
// Broken - uses floating point for monetary calculation!public static void main(String[] args) { double funds = 1.00; int itemsBought = 0;
for (double price = .10; funds >= price; price += .10) { funds -= price; itemsBought++;
} System.out.println(itemsBought + " items bought."); System.out.println("Change: $" + funds);}public static void main(String[] args) { final BigDecimal TEN_CENTS = new BigDecimal(".10"); int itemsBought = 0; BigDecimal funds = new BigDecimal("1.00"); for (BigDecimal price = TEN_CENTS; funds.compareTo(price) >= 0; price = price.add(TEN_CENTS)) { itemsBought++; funds = funds.subtract(price); } System.out.println(itemsBought + " items bought."); System.out.println("Money left over: $" + funds);}public static void main(String[] args) { int itemsBought = 0; int funds = 100; for (int price = 10; funds >= price; price += 10) { itemsBought++; funds -= price; } System.out.println(itemsBought + " items bought."); System.out.println("Money left over: "+ funds + " cents");}Item 32: Avoid strings where other types are more appropriate
Strings are poor substitutes for other value types. More generally, if there's an appropriate value type, whether
primitive or object reference, you should use it; if there isn't, you should write one.
Strings are poor substitutes for aggregate types. A better approach is simply to write a class to represent the aggregate, often a private static member class
Strings are poor substitutes for capabilities. Occasionally, strings are used to grant access to some functionality, replace the string with an unforgeable key (sometimes called a capability).
Item 33: Beware the performance of string concatenation
Don't use the string concatenation operator to combine more than a few strings unless performance is irrelevant. Use StringBuffer's append method instead. Alternatively, use a character array, or process the strings one at a time instead of combining them.
Item 34: Refer to objects by their interfaces
If appropriate interface types exist, parameters, return values, variables, and fields should all be declared using interface types.
// Good - uses interface as typeList subscribers = new Vector();// Bad - uses class as type!Vector subscribers = new Vector();declaration could be changed to read
List subscribers = new ArrayList();then it would be incorrect to substitute ArrayList for Vector in the declaration.
It is entirely appropriate to refer to an object by a class rather than an interface if no appropriate interface exists.
For example, it is perfectly appropriate to use a value class as a parameter, variable, field, or return type.
If an object belongs to such a class-based framework, it is preferable to refer to it by the relevant base class, which is
typically abstract, rather than by its implementation class.
A final case in which there is no appropriate interface type is that of classes that implement an interface but provide extra methods not found in the interface鈥攆or example, LinkedList. Such a class should be used only to refer to its instances if the program relies on the extra methods: it should never be used as a parameter type (Item 25).
Item 35: Prefer interfaces to reflection
Reflection comes at a price:
You lose all the benefits of compile-time type checking.
The code required to perform reflective access is clumsy and verbose.
Performance suffers.
As a rule, objects should not be accessed reflectively in normal applications at run time.
You can obtain many of the benefits of reflection while incurring few of its costs by using it only in a very limited form. For many programs that must use a class unavailable at compile time, there exists at compile time an appropriate interface or superclass by which to refer to the class (Item 34). If this is the case, you can create instances reflectively and access them normally via their interface or superclass. If the appropriate constructor has no parameters, as is usually the case, then you don't even need to use the java.lang.reflect package; the Class.newInstance method provides the required functionality.
// Reflective instantiation with interface accesspublic static void main(String[] args) {// Translate the class name into a class objectClass cl = null;try {cl = Class.forName(args[0]);} catch(ClassNotFoundException e) {System.err.println("Class not found.");System.exit(1);}// Instantiate the classSet s = null;try {s = (Set) cl.newInstance();} catch(IllegalAccessException e) {System.err.println("Class not accessible.");System.exit(1);} catch(InstantiationException e) {System.err.println("Class not instantiable.");System.exit(1);}// Exercise the sets.addAll(Arrays.asList(args).subList(1, args.length-1));System.out.println(s);}Item 36: Use native methods judiciously
Think twice before using native methods. Rarely, if ever, use them for improved performance. If you must use native methods to access low-level resources or legacy libraries, use as little native code as possible and test it thoroughly. A single bug in the native code can corrupt your entire application.
Item 37: Optimize judiciously
Strive to write good programs rather than fast ones.
Strive to avoid design decisions that limit performance.
Consider the performance consequences of your API design decisions.
It is a very bad idea to warp an API to achieve good performance.
Measure performance before and after each attempted optimization.
Item 38: Adhere to generally accepted naming conventions
Internalize the standard naming conventions and learn to use them as second nature. The typographical conventions are straightforward and largely unambiguous; the grammatical conventions are more complex and looser. To quote from The Java Language Specification, "These conventions should not be followed slavishly if long-held conventional usage dictates otherwise." Use common sense.
Scott@JAVA 2005-12-18 06:26 鍙戣〃璇勮
]]>Scott@JAVA 2005-12-18 06:25 鍙戣〃璇勮
]]>Scott@JAVA 2005-12-18 06:24 鍙戣〃璇勮
]]>Item 7: Obey the general contract when overriding equals
This is the right thing to do if any of the following conditions apply:
a) Each instance of the class is inherently unique.
b) You don't care whether the class provides a "logical equality" test.
c) A superclass has already overridden equals, and the behaviour inherited from the superclass is appropriate for this class.
d) The class is private or package-private, and you are certain that its equals method will never be invoked.
Here's a recipe for a high-quality equals method:
1) Use the == operator to check if the argument is a reference to this object.
2) Use the instanceof operator to check if the argument is of the correct type.
3) Cast the argument to the correct type.
4) For each "significant" field in the class, check to see if that field of the argument matches the corresponding field of this object.
5) When you are finished writing your equals method, ask yourself three questions: Is it symmetric, is it transitive, and is it consistent?
Here are a few final caveats:
a) Always override hashCode when you override equals.
b) Don't try to be too clever.
c) Don't write an equals method that relies on unreliable resources.
d) Don't substitute another type for Object in the equals declaration.
Item 8: Always override hashCode when you override equals
You must override hashCode in every class that overrides equals.
The key provision that is violated when you fail to override hashCode is the second one:
Equal objects must have equal hash codes.
Here is a simple recipe:
1. Store some constant nonzero value, say 17, in an int variable called result.
2. For each significant field f in your object (each field taken into account by the equals method, that is), do the following:
a. Compute an int hash code c for the field:
i. If the field is a boolean, compute (f ? 0 : 1).
ii. If the field is a byte, char, short, or int, compute (int)f.
iii. If the field is a long, compute (int)(f ^ (f >>> 32)).
iv. If the field is a float compute Float.floatToIntBits(f).
v. If the field is a double, compute Double.doubleToLongBits(f), and then hash the resulting long as in step 2.a.iii.
vi. If the field is an object reference and this class's equals method compares the field by recursively invoking equals, recursively invoke hashCode on the field. If a more complex comparison is required, compute a "canonical representation" for this field and invoke hashCode on the canonical representation. If the value of the field is null, return 0 (or some other constant, but 0 is traditional).
vii. If the field is an array, treat it as if each element were a separate field. That is, compute a hash code for each significant element by applying these rules recursively, and combine these values as described in step 2.b.
b. Combine the hash code c computed in step a into result as follows: result = 37*result + c;
3. Return result.
4. When you are done writing the hashCode method, ask yourself whether equal
instances have equal hash codes. If not, figure out why and fix the problem
Do not be tempted to exclude significant parts of an object from the hash code computation to improve performance.
Item 9: Always override toString
Providing a good toString implementation makes your class much more pleasant to use.
When practical, the toString method should return all of the interesting information contained in the object.
Whether or not you decide to specify the format, you should clearly document your intentions.
It is always a good idea to provide programmatic access to all of the information contained in the value returned by toString.
Item 10: Override clone judiciously
If you override the clone method in a nonfinal class, you should return an object obtained by invoking super.clone.
In practice, a class the implements Cloneable is expected to provide a properly functioning public clone method.
public Object clone() { try { return super.clone(); } catch(CloneNotSupportedException e) { throw new Error("Assertion failure"); // Can't happen }}If, however, your object contains fields that refer to mutable objects, using this clone
implementation can be disastrous. Neglect the rest, refer to the book for more details...
Item 11: Consider implementing Comparable
The compareTo method is not declared in Object. Rather, it is the sole method in the java.lang.Comparable interface.
Array element comparisons of Chapter 11: Collections of Objects in <<Thinking in Java>> 3rd ed. Revision 4.0, has a more practical way to explain this.
Scott@JAVA 2005-12-18 06:23 鍙戣〃璇勮
]]>Scott@JAVA 2005-12-18 06:22 鍙戣〃璇勮
]]>