Chapter 5. Substitutes for C Constructs
Item 19: Replace structures with classes
The C struct construct was omitted from the Java programming language because a class does everything a structure does and more.
Item 20: Replace unions with class hierarchies
A structure containing a union and a tag is sometimes called a discriminated union.
A discriminated union is really just a pallid imitation of a class hierarchy.
A class hierarchy provides type safety, simple and clear coding, extensibility and flexibility.
Item 21: Replace enum constructs with classes
Item 22: Replace function pointers with classes and interfaces
Function pointers were omitted from the Java programming language because object references can be used to provide the same functionality
The primary use of C’s function pointers is to implement the Strategy pattern.To implement this pattern in the Java programming language, declare an interface to represent the strategy and a class that implements this interface for each concrete strategy.
Chapter 6. Methods
Item 23: Check parameters for validity
Detect errors as soon as possible after they occur.
Clearly document all such restrictions on parameters and enforce them with checks at the beginning of the method body.
For public methods, use the Javadoc @throws tag to document the exception that will be thrown if a restriction on parameter values is violated (Item 44).
Nonpublic methods should generally check their parameters using assertions rather than normal checks.
It is particularly important to check the validity of parameters that are not used by a method but are stored away for later use.
It is very important to check the validity of parameters to constructors to prevent the construction of an object that violates class invariants.
An important exception is the case in which the validity check would be expensive or impractical and the validity check is performed implicitly in the process of doing the computation.
Use the exception translation idiom described in Item 43 to translate the natural exception into the correct one.
You should design methods to be as general as it is practical to make them.
Item 24: Make defensive copies when needed
You must program defensively with the assumption that clients of your class will do their best to destroy its invariants.
Defensive copies are made before checking the validity of the parameters (Item 23), and the validity check is performed on the copies rather than on the originals.
Do not use the clone method to make a defensive copy of a parameter whose type is subclassable by untrusted parties.
Return defensive copies of mutable internal fields.
Item 25: Design method signatures carefully
Choose method names carefully.
Don’t go overboard in providing convenience methods. When in doubt, leave it out.
Avoid long parameter lists.Long sequences of identically typed parameters are especially harmful.
For parameter types, favor interfaces over classes.
Use function objects (Item 22) judiciously.
Item 26: Use overloading judiciously
The choice of which overloading to invoke is made at compile time.
Selection among overloaded methods is static, while selection among overridden methods is dynamic.
Avoid confusing uses of overloading.A safe, conservative policy is never to export two overloadings with the same number of parameters.
Item 27: Return zero-length arrays, not nulls
There is no reason ever to return null from an array-valued method instead of returning a zero-length array
Item 28: Write doc comments for all exposed API elements
The doc comment for a method should describe succinctly the contract between the method and its client.
Methods should document preconditions, postconditions and any side effects
Chapter 7. General Programming
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.
Kep methods small and focused.
Item 30: Know and use the libraries
Don’t reinvent the wheel
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.
Additions in Java 1.4 – java.util.regex, java.util.prefs, java.nio, java.util.LinkedHashSet, LinkedHashMap, IdentityHashMap
Item 31: Avoid float and double if exact answers are required
The float and double types are particularly ill-suited for monetary calculations.
If the quantities don’t exceed nine decimal digits, you can use ; if they don’t exceed eighteen digits, you can use . If the quantities int long exceed eighteen digits, you must use BigDecimal
Item 32: Avoid strings where other types are more appropriate
Strings are poor substitutes for other value types, enumerated types, aggregate types and capabilities.
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 StrinfBuffer’s method instead.
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.
If you get into the habit of using interfaces as types, your program will be much more flexible.
It is entirely appropriate to refer to an object by a class rather than an interface if no appropriate interface exists.
Item 35: Prefer interfaces to reflection
Reflection is a powerful facility that is required for certain sophisticated system programming tasks, but it has many disadvantages.
If you are writing a program that has to work with classes unknown at compile time you should, if at all possible, use reflection only to instantiate objects and access the objects using some interface or superclass that is known at compile time.
Item 36: Use native methods judiciously
As of release 1.3, it is rarely advisable to use native methods for improved performance.
Item 37: Optimize judiciously
Don’t sacrifice sound architectural principles for performance.
Strive to avoid design decisions that limit performance.
Consider the performance consequences of your API design decisions.
Measure performance before and after each attempted optimization.
Item 38: Adhere to generally accepted naming conventions
