Sách Effective Java™ Second Edition - Joshua Bloch

Effective Java™
Second Edition
Joshua Bloch


Contents
Foreword . xiii
Preface xv
Acknowledgments xix
1 Introduction 1
2 Creating and Destroying Objects .5
Item 1: Consider static factory methods instead of constructors . 5
Item 2: Consider a builder when faced with many constructor
parameters . 11
Item 3: Enforce the singleton property with a private
constructor or an enum type . 17
Item 4: Enforce noninstantiability with a private constructor 19
Item 5: Avoid creating unnecessary objects . 20
Item 6: Eliminate obsolete object references . 24
Item 7: Avoid finalizers . 27
3 Methods Common to All Objects 33
Item 8: Obey the general contract when overriding equals . 33
Item 9: Always override hashCode when you
override equals . 45
Item 10: Always override toString 51
Item 11: Override clone judiciously 54
Item 12: Consider implementing Comparable 62
x CONTENTS
4 Classes and Interfaces .67
Item 13: Minimize the accessibility of classes and members 67
Item 14: In public classes, use accessor methods,
not public fields . 71
Item 15: Minimize mutability 73
Item 16: Favor composition over inheritance 81
Item 17: Design and document for inheritance or else prohibit it 87
Item 18: Prefer interfaces to abstract classes 93
Item 19: Use interfaces only to define types . 98
Item 20: Prefer class hierarchies to tagged classes . 100
Item 21: Use function objects to represent strategies . 103
Item 22: Favor static member classes over nonstatic . 106
5 Generics .109
Item 23: Don’t use raw types in new code . 109
Item 24: Eliminate unchecked warnings . 116
Item 25: Prefer lists to arrays . 119
Item 26: Favor generic types 124
Item 27: Favor generic methods . 129
Item 28: Use bounded wildcards to increase API flexibility . 134
Item 29: Consider typesafe heterogeneous containers 142
6 Enums and Annotations 147
Item 30: Use enums instead of int constants . 147
Item 31: Use instance fields instead of ordinals . 158
Item 32: Use EnumSet instead of bit fields . 159
Item 33: Use EnumMap instead of ordinal indexing . 161
Item 34: Emulate extensible enums with interfaces 165
Item 35: Prefer annotations to naming patterns . 169
Item 36: Consistently use the Override annotation 176
Item 37: Use marker interfaces to define types . 179
7 Methods .181
Item 38: Check parameters for validity . 181
Item 39: Make defensive copies when needed 184
Item 40: Design method signatures carefully . 189
Item 41: Use overloading judiciously . 191
CONTENTS xi
Item 42: Use varargs judiciously 197
Item 43: Return empty arrays or collections, not nulls . 201
Item 44: Write doc comments for all exposed API elements 203
8 General Programming .209
Item 45: Minimize the scope of local variables . 209
Item 46: Prefer for-each loops to traditional for loops . 212
Item 47: Know and use the libraries . 215
Item 48: Avoid float and double if exact answers
are required . 218
Item 49: Prefer primitive types to boxed primitives . 221
Item 50: Avoid strings where other types are more appropriate 224
Item 51: Beware the performance of string concatenation 227
Item 52: Refer to objects by their interfaces . 228
Item 53: Prefer interfaces to reflection . 230
Item 54: Use native methods judiciously 233
Item 55: Optimize judiciously 234
Item 56: Adhere to generally accepted naming conventions . 237
9 Exceptions .241
Item 57: Use exceptions only for exceptional conditions . 241
Item 58: Use checked exceptions for recoverable conditions
and runtime exceptions for programming errors . 244
Item 59: Avoid unnecessary use of checked exceptions 246
Item 60: Favor the use of standard exceptions 248
Item 61: Throw exceptions appropriate to the abstraction . 250
Item 62: Document all exceptions thrown by each method 252
Item 63: Include failure-capture information in
detail messages 254
Item 64: Strive for failure atomicity . 256
Item 65: Don’t ignore exceptions . 258
10 Concurrency 259
Item 66: Synchronize access to shared mutable data . 259
Item 67: Avoid excessive synchronization 265
Item 68: Prefer executors and tasks to threads 271
Item 69: Prefer concurrency utilities to wait and notify . 273
xii CONTENTS
Item 70: Document thread safety 278
Item 71: Use lazy initialization judiciously 282
Item 72: Don’t depend on the thread scheduler . 286
Item 73: Avoid thread groups . 288
11 Serialization 289
Item 74: Implement Serializable judiciously . 289
Item 75: Consider using a custom serialized form . 295
Item 76: Write readObject methods defensively . 302
Item 77: For instance control, prefer enum types
to readResolve 308
Item 78: Consider serialization proxies instead of serialized
instances 312
Appendix: Items Corresponding to First Edition 317
References 321
Index 327
xiii
Foreword
IF a colleague were to say to you, “Spouse of me this night today manufactures the
unusual meal in a home. You will join?” three things would likely cross your mind:
third, that you had been invited to dinner; second, that English was not your colleague’s
first language; and first, a good deal of puzzlement.
If you have ever studied a second language yourself and then tried to use it
outside the classroom, you know that there are three things you must master: how
the language is structured (grammar), how to name things you want to talk about
(vocabulary), and the customary and effective ways to say everyday things
(usage). Too often only the first two are covered in the classroom, and you find
native speakers constantly suppressing their laughter as you try to make yourself
understood.
It is much the same with a programming language. You need to understand the
core language: is it algorithmic, functional, object-oriented? You need to know the
vocabulary: what data structures, operations, and facilities are provided by the
standard libraries? And you need to be familiar with the customary and effective
ways to structure your code. Books about programming languages often cover
only the first two, or discuss usage only spottily. Maybe that’s because the first
two are in some ways easier to write about. Grammar and vocabulary are properties
of the language alone, but usage is characteristic of a community that uses it.
The Java programming language, for example, is object-oriented with single
inheritance and supports an imperative (statement-oriented) coding style within
each method. The libraries address graphic display support, networking, distributed
computing, and security. But how is the language best put to use in practice?
There is another point. Programs, unlike spoken sentences and unlike most
books and magazines, are likely to be changed over time. It’s typically not enough
to produce code that operates effectively and is readily understood by other persons;
one must also organize the code so that it is easy to modify. There may be
ten ways to write code for some task T. Of those ten ways, seven will be awkward,
inefficient, or puzzling. Of the other three, which is most likely to be similar to the
code needed for the task T' in next year’s software release?
xiv FOREWORD
There are numerous books from which you can learn the grammar of the Java
Programming Language, including The Java™ Programming Language by Arnold,
Gosling, and Holmes [Arnold05] or The Java™ Language Specification by Gosling,
Joy, yours truly, and Bracha [JLS]. Likewise, there are dozens of books on
the libraries and APIs associated with the Java programming language.
This book addresses your third need: customary and effective usage. Joshua
Bloch has spent years extending, implementing, and using the Java programming
language at Sun Microsystems; he has also read a lot of other people’s code,
including mine. Here he offers good advice, systematically organized, on how to
structure your code so that it works well, so that other people can understand it, so
that future modifications and improvements are less likely to cause headaches—
perhaps, even, so that your programs will be pleasant, elegant, and graceful.
Guy L. Steele Jr.
Burlington, Massachusetts
April 2001


Preface
Preface to the Second Edition
A lot has happened to the Java platform since I wrote the first edition of this book
in 2001, and it’s high time for a second edition. The most significant set of changes
was the addition of generics, enum types, annotations, autoboxing, and the for-each
loop in Java 5. A close second was the addition of the new concurrency library,
java.util.concurrent, also released in Java 5. With Gilad Bracha, I had the good
fortune to lead the teams that designed the new language features. I also had the
good fortune to serve on the team that designed and developed the concurrency
library, which was led by Doug Lea.
The other big change in the platform is the widespread adoption of modern
Integrated Development Environments (IDEs), such as Eclipse, IntelliJ IDEA, and
NetBeans, and of static analysis tools, such as FindBugs. While I have not been
involved in these efforts, I’ve benefited from them immensely and learned how
they affect the Java development experience.
In 2004, I moved from Sun to Google, but I’ve continued my involvement in
the development of the Java platform over the past four years, contributing to the
concurrency and collections APIs through the good offices of Google and the Java
Community Process. I’ve also had the pleasure of using the Java platform to
develop libraries for use within Google. Now I know what it feels like to be a user.
As was the case in 2001 when I wrote the first edition, my primary goal is to
share my experience with you so that you can imitate my successes while avoiding
my failures. The new material continues to make liberal use of real-world examples
from the Java platform libraries.
The first edition succeeded beyond my wildest expectations, and I’ve done my
best to stay true to its spirit while covering all of the new material that was
required to bring the book up to date. It was inevitable that the book would grow,
and grow it did, from fifty-seven items to seventy-eight. Not only did I add
twenty-three items, but I thoroughly revised all the original material and retired a
xvi PREFACE
few items whose better days had passed. In the Appendix, you can see how the
material in this edition relates to the material in the first edition.
In the Preface to the First Edition, I wrote that the Java programming language
and its libraries were immensely conducive to quality and productivity, and a joy
to work with. The changes in releases 5 and 6 have taken a good thing and made it
better. The platform is much bigger now than it was in 2001 and more complex,
but once you learn the patterns and idioms for using the new features, they make
your programs better and your life easier. I hope this edition captures my continued
enthusiasm for the platform and helps make your use of the platform and its
new features more effective and enjoyable.
San Jose, California
April 2008
Preface to the First Edition
In 1996 I pulled up stakes and headed west to work for JavaSoft, as it was then
known, because it was clear that 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-alifetime
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
PREFACE xvii
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
[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 welldesigned
APIs for the components of the system.
No language is perfect, but some 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.
Cupertino, California
April 2001