PRODUCT SUPPORT ANNOUNCEMENT
Some videos and Web Editions may be returning errors on launch. Learn more.
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.
Use Exceptions Only for Exceptional Conditions.
Use Checked Exceptions for Recoverable Conditions, Runtime Exceptions for Programming Errors.
Avoid Unnecessary Use of Checked Exceptions.
Favor the Use of Standard Exceptions.
Throw Exceptions Appropriate to the Abstraction.
Document All Exceptions Thrown by Each Method.
Include Failure-Capture Information in Detail Messages.
Strive for Failure Atomicity.
Don't Ignore Exceptions.
Synchronize Access to Shared Mutable Data.
Avoid Excessive Synchronization.
Never Invoke Wait Outside a Loop.
Don't Depend on the Thread Scheduler.
Avoid Thread Groups.
Implement Serializable Judiciously.
Consider Using a Custom Serialized Form.
Write ReadObject Methods Defensively.
Provide a ReadResolve Method when Necessary.
In 1996 I pulled up stakes and headed west to work for JavaSoft, as it was then known, because it was clear that was where the action was. In the intervening five years I've served as Java Platform Libraries Architect. I've designed, implemented and maintained many of the libraries, and served as a consultant for many others. Presiding over these libraries as the Java platform matured was a once-in-a-lifetime opportunity. It is no exaggeration to say that I had the privilege to work with some of the great software engineers of our generation. In the process, I learned a lot about the Java programming language--what works, what doesn't, and how to use the language and its libraries to best effect.
This book is my attempt to share my experience with you, so that you can imitate my successes while avoiding my failures. I borrowed the format from Scott Meyers's Effective C++ Meyers98, which consists of fifty items, each conveying one specific rule for improving your programs and designs. I found the format to be singularly effective and I hope you do too.
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.