Chapter
1. Introduction
This book is designed to help you make the most effective use of the Java™ programming language and its fundamental libraries, java.lang, java.util, and, to a lesser extent, java.io. The book discusses other libraries from time to time, but it does not cover graphical user interface programming or enterprise APIs.
This book consists of fifty-seven items, each of which conveys one rule. The rules capture practices generally held to be beneficial by the best and most experienced programmers. The items are loosely grouped into nine chapters, each concerning one broad aspect of software design. The book is not intended to be read from cover to cover: Each item stands on its own, more or less. The items are heavily cross-referenced so you can easily plot your own course through the book.
Most items are illustrated with program examples. A key feature of this book is that it contains code examples illustrating many design patterns and idioms. Some are old, like Singleton (Item 2), and others are new, like Finalizer Guardian (Item 6) and Defensive readResolve (Item 57). A separate index is provided for easy access to these patterns and idioms (page 239). Where appropriate, they are cross-referenced to the standard reference work in this area [Gamma95].
Many items contain one or more program examples illustrating some practice to be avoided. Such examples, sometimes known as antipatterns, are clearly labeled with a comment such as "// Never do this!" In each case, the item explains why the example is bad and suggests an alternative approach.
This book is not for beginners: it assumes that you are already comfortable with the Java programming language. If you are not, consider one of the many fine introductory texts [Arnold00, Campione00]. While the book is designed to be accessible to anyone with a working knowledge of the language, it should provide food for thought even for advanced programmers.
Most of the rules in this book derive from a few fundamental principles. Clarity and simplicity are of paramount importance. The user of a module should never be surprised by its behavior. Modules should be as small as possible but no smaller. (As used in this book, the term module refers to any reusable software component, from an individual method to a complex system consisting of multiple packages.) Code should be reused rather than copied. The dependencies between modules should be kept to a minimum. Errors should be detected as soon as possible after they are made, ideally at compile time.
While the rules in this book do not apply 100 percent of the time, they do characterize best programming practices in the great majority of cases. You should not slavishly follow these rules, but you should violate them only occasionally and with good reason. Learning the art of programming, like most other disciplines, consists of first learning the rules and then learning when to violate them.
For the most part, this book is not about performance. It is about writing programs that are clear, correct, usable, robust, flexible, and maintainable. If you can do that, it's usually a relatively simple matter to get the performance you need (Item 37). Some items do discuss performance concerns, and a few of these items provide performance numbers. These numbers, which are introduced with the phrase "On my machine," should be regarded as approximate at best.
For what it's worth, my machine is an aging homebuilt 400 MHz Pentium� II with 128 megabytes of RAM, running Sun's 1.3 release of the Java 2 Standard Edition Software Development Kit (SDK) atop Microsoft Windows NT� 4.0. This SDK includes Sun's Java HotSpotT Client VM, a state-of-the-art JVM implementation designed for client use.
When discussing features of the Java programming language and its libraries, it is sometimes necessary to refer to specific releases. For brevity, this book uses "engineering version numbers" in preference to official release names. Table 1.1 shows the correspondence between release names and engineering version numbers.
Table�1.1. Java Platform Versions
Official Release Name
|
Engineering Version Number
|
|---|
JDK 1.1.x / JRE 1.1.x |
1.1 |
Java 2 Platform, Standard Edition, v 1.2 |
1.2 |
Java 2 Platform, Standard Edition, v 1.3 |
1.3 |
Java 2 Platform, Standard Edition, v 1.4 |
1.4 |
While features introduced in the 1.4 release are discussed in some items, program examples, with very few exceptions, refrain from using these features. The examples have been tested on releases 1.3. Most, if not all, of them should run without modification on release 1.2.
The examples are reasonably complete, but they favor readability over completeness. They freely use classes from the packages java.util and java.io. In order to compile the examples, you may have to add one or both of these import statements:
import java.util.*;
import java.io.*;
Other boilerplate is similarly omitted. The book's Web site, http://java.sun.com/docs/books/effective, contains an expanded version of each example, which you can compile and run.
For the most part, this book uses technical terms as they are defined in The Java Language Specification, Second Edition [JLS]. A few terms deserve special mention. The language supports four kinds of types: interfaces, classes, arrays, and primitives. The first three are known as reference types. Class instances and arrays are objects; primitive values are not. A class's members consist of its fields, methods, member classes, and member interfaces. A method's signature consists of its name and the types of its formal parameters; the signature does not include the method's return type.
This book uses a few terms differently from the The Java Language Specification. Unlike The Java Language Specification, this book uses inheritance as a synonym for subclassing. Instead of using the term inheritance for interfaces, this book simply states that a class implements an interface or that one interface extends another. To describe the access level that applies when none is specified, this book uses the descriptive term package-private instead of the technically correct term default access [JLS, 6.6.1].
This book uses a few technical terms that are not defined in The Java Language Specification. The term exported API, or simply API, refers to the classes, interfaces, constructors, members, and serialized forms by which a programmer accesses a class, interface, or package. (The term API, which is short for application programming interface, is used in preference to the otherwise preferable term interface to avoid confusion with the language construct of that name.) A programmer who writes a program that uses an API is referred to as a user of the API. A class whose implementation uses an API is a client of the API.
Classes, interfaces, constructors, members, and serialized forms are collectively known as API elements. An exported API consists of the API elements that are accessible outside of the package that defines the API. These are the API elements that any client can use and the author of the API commits to support. Not coincidentally, they are also the elements for which the Javadoc utility generates documentation in its default mode of operation. Loosely speaking, the exported API of a package consists of the public and protected members and constructors of every public class or interface in the package.
No comments:
Post a Comment