Buy 2+ books or eBooks, save 55% through December 1. Use code BOOKSGIVING. Shop the sale.
A new edition of this title is available, ISBN-10: 0321356683 ISBN-13: 9780321356680
2. Creating and Destroying Objects.
Consider Providing Static Factory Methods Instead of Constructors.
Enforce the Singleton Property with a Private Constructor.
Enforce Noninstantiability with a Private Constructor.
Avoid Creating Duplicate Objects.
Eliminate Obsolete Object References.
Obey the General Contract when Overriding Equals.
Always Override HashCode When You Override Equals.
Always Override to String.
Override Clone Judiciously.
Consider Implementing Comparable.
Minimize the Accessibility of Classes and Members.
Favor Composition Over Inheritance.
Design and Document for Inheritance or Else Prohibit It.
Prefer Interfaces to Abstract Classes.
Use Interfaces Only to Define Types.
Favor Static Member Classes Over Non-Static.
Replace Structures with Classes.
Replace Unions with Class Hierarchies.
Replace Enums with Classes.
Replace Function Pointers with Classes and Interfaces.
Check Parameters for Validity.
Make Defensive Copies when Needed.
Design Method Signatures Carefully.
Use Overloading Judiciously.
Return Zero-Length Arrays, Not Nulls.
Write Doc Comments for All Exposed API Elements.
Minimize the Scope of Local Variables.
Know and Use the Libraries.
Avoid Float and Double if Exact Answers are Required.
Avoid Strings where Other Types are More Appropriate.
Beware the Performance of String Concatenation.
Refer to Objects by their Interfaces.
Prefer Interfaces to Reflection.
Use Native Methods Judiciously.
Adhere to Generally Accepted Naming Conventions.
In many cases, I took the liberty of illustrating the items with real-world examples from the Java platform libraries. When describing something that could have been done better, I tried to pick on code that I wrote myself, but occasionally I pick on something written by a colleague. I sincerely apologize if, despite my best efforts, I've offended anyone. Negative examples are cited not to cast blame but in the spirit of cooperation, so that all of us can benefit from the experience of those who've gone before.
While this book is not targeted solely at developers of reusable components, it is inevitably colored by my experience writing such components over the past two decades. I naturally think in terms of exported APIs (Application Programming Interfaces) and I encourage you to do likewise. Even if you aren't developing reusable components, thinking in these terms tends to improve the quality of the software you write. Furthermore, it's not uncommon to write a reusable component without knowing it: you write something useful, share it with your buddy across the hall, and before long you have half a dozen users. At this point, you no longer have the flexibility to change the API at will, and are thankful for all the effort that you put into designing the API when you first wrote the software.
My focus on API design may seem a bit unnatural to devotees of the new lightweight software development methodologies, such as Extreme Programming Explained Beck99. These methodologies emphasize writing the simplest program that could possibly work. If you're using one of these methodologies you'll find that a focus on API design serves you well in the refactoring process. The fundamental goals of refactoring are the improvement of system structure and the avoidance of code duplication. These goals are impossible to achieve in the absence of well-designed APIs for the components of the system.
No language is perfect, but some of them are excellent. I have found the Java programming language and its libraries to be immensely conducive to quality and productivity, and a joy to work with. I hope this book captures my enthusiasm and helps make your use of the language more effective and enjoyable.