《Effective Java》：深度解析编程语言指南

需积分: 0 177 浏览量更新于2024-07-23 收藏 2.79MB PDF 举报

《Effective Java: Programming Language Guide》是由著名软件工程师Joshua Bloch所著，于2001年6月首次出版，由Addison-Wesley出版社发行。这本书旨在为Java开发者提供一本深入且实用的指南，专注于提升编程技能，使代码更具清晰性、正确性、健壮性和可重用性。作者在书中分享了57条宝贵的编程原则（"规则之眼"），这些都是开发者在日常编程中常遇到挑战的解决方案。本书的核心内容围绕着Java编程语言的最佳实践展开，它不仅介绍了Java平台技术的专家级描述，还揭示了编写高效、简洁和稳健代码的方法与避免陷阱的策略。作者强调了静态工厂方法（而非构造函数）的重要性，尤其是在创建对象时，这有助于控制实例化过程，提高代码的组织和可维护性。第二章“Creating and Destroying Objects”（创建和销毁对象）深入探讨了如何设计合理的对象生命周期管理。其中第一条规则建议提供静态工厂方法，而不是仅仅依赖构造函数，这是因为工厂方法可以在不暴露类的内部细节的情况下创建对象，并且可以处理复杂或者有副作用的初始化过程。同时，对于实现单例模式，作者强调了使用私有构造函数以防止意外实例化，确保在整个程序中只有一个实例存在。通过阅读这本书，Java开发者可以期待获得以下收获： 1. 深入理解Java编程语言的高级特性和最佳实践。 2. 学习如何编写更具可读性、可靠性和效率的代码。 3. 掌握处理常见编程问题的实用技巧和策略。 4. 提高代码质量和团队协作效率，减少维护成本。 5. 理解并遵循Java设计模式，如工厂模式和单例模式。《Effective Java》是一本不可多得的Java编程参考书籍，无论是初学者还是经验丰富的开发者，都能从中受益匪浅，提升自己的编程水平。无论是在编写新代码还是优化现有项目时，都可以参考书中的规则来指导实践，确保代码质量的不断提升。

Effective Java: Programming Language Guide

// Singleton with static factory

public class Elvis {

private static final Elvis INSTANCE = new Elvis();

private Elvis() {

...

}

public static Elvis getInstance() {

return INSTANCE;

}

... // Remainder omitted

}

All calls to the static method,

Elvis.getInstance

, return the same object reference, and no

other

Elvis

instance will ever be created.

The main advantage of the first approach is that the declarations of the members comprising

the class make it clear that the class is a singleton: the public static field is final, so the field

will always contain the same object reference. There may also be a slight performance

advantage to the first approach, but a good JVM implementation should be able to eliminate it

by inlining the call to the static factory method in the second approach.

The main advantage of the second approach is that it gives you the flexibility to change your

mind about whether the class should be a singleton without changing the API. The static

factory method for a singleton returns the sole instance of the class but could easily be

modified to return, say, a unique instance for each thread that invokes the method.

On balance, then, it makes sense to use the first approach if you're absolutely sure that the

class will forever remain a singleton. Use the second approach if you want to reserve

judgment in the matter.

To make a singleton class serializable (Chapter 10), it is not sufficient merely to add

implements

Serializable

to its declaration. To maintain the singleton guarantee, you must

also provide a

readResolve

method (Item 57). Otherwise, each deserialization of a serialized

instance will result in the creation of a new instance, leading, in the case of our example, to

spurious

Elvis sightings. To prevent this, add the following readResolve method to the

Elvis class:

// readResolve method to preserve singleton property

private Object readResolve() throws ObjectStreamException {

* Return the one true Elvis and let the garbage collector

* take care of the Elvis impersonator.

return INSTANCE;

}

A unifying theme underlies this Item and Item 21, which describes the typesafe enum pattern.

In both cases, private constructors are used in conjunction with public static members to

ensure that no new instances of the relevant class are created after it is initialized. In the case

of this item, only a single instance of the class is created; in Item 21, one instance is created

Effective Java: Programming Language Guide

for each member of the enumerated type. In the next item (Item 3), this approach is taken one

step further: the absence of a public constructor is used to ensure that no instances of a class

are ever created.

Item 3: Enforce noninstantiability with a private constructor

Occasionally you'll want to write a class that is just a grouping of static methods and static

fields. Such classes have acquired a bad reputation because some people abuse them to write

procedural programs in object-oriented languages, but they do have valid uses. They can be

used to group related methods on primitive values or arrays, in the manner of

java.lang.Math

java.util.Arrays

, or to group static methods on objects that

implement a particular interface, in the manner of

java.util.Collections

. They can also

be used to group methods on a final class, in lieu of extending the class.

Such utility classes were not designed to be instantiated: An instance would be nonsensical. In

the absence of explicit constructors, however, the compiler provides a public, parameterless

default constructor. To a user, this constructor is indistinguishable from any other. It is not

uncommon to see unintentionally instantiable classes in published APIs.

Attempting to enforce noninstantiability by making a class abstract does not work.

The class can be subclassed and the subclass instantiated. Furthermore, it misleads the user

into thinking the class was designed for inheritance (Item 15). There is, however, a simple

idiom to ensure noninstantiability. A default constructor is generated only if a class contains

no explicit constructors, so a class can be made noninstantiable by including a single

explicit private constructor:

// Noninstantiable utility class

public class UtilityClass {

// Suppress default constructor for noninstantiability

private UtilityClass() {

// This constructor will never be invoked

}

... // Remainder omitted

}

Because the explicit constructor is private, it is inaccessible outside of the class. It is thus

guaranteed that the class will never be instantiated, assuming the constructor is not invoked

from within the class itself. This idiom is mildly counterintuitive, as the constructor is

provided expressly so that it cannot be invoked. It is therefore wise to include a comment

describing the purpose of the constructor.

As a side effect, this idiom also prevents the class from being subclassed. All constructors

must invoke an accessible superclass constructor, explicitly or implicitly, and a subclass

would have no accessible constructor to invoke.

Item 4: Avoid creating duplicate objects

It is often appropriate to reuse a single object instead of creating a new functionally equivalent

object each time it is needed. Reuse can be both faster and more stylish. An object can always

be reused if it is immutable (Item 13).

Effective Java: Programming Language Guide

As an extreme example of what not to do, consider this statement:

String s = new String("silly");

// DON'T DO THIS!

The statement creates a new String instance each time it is executed, and none of those

object creations is necessary. The argument to the

String constructor ("silly") is itself a

String instance, functionally identical to all of the objects created by the constructor. If this

usage occurs in a loop or in a frequently invoked method, millions of

String instances can be

created needlessly.

The improved version is simply the following:

String s = "No longer silly";

This version uses a single String instance, rather than creating a new one each time it is

executed. Furthermore, it is guaranteed that the object will be reused by any other code

running in the same virtual machine that happens to contain the same string literal [JLS,

3.10.5].

You can often avoid creating duplicate objects by using static factory methods (Item 1) in

preference to constructors on immutable classes that provide both. For example, the static

factory method

Boolean.valueOf(String) is almost always preferable to the constructor

Boolean(String). The constructor creates a new object each time it's called while the static

factory method is never required to do so.

In addition to reusing immutable objects, you can also reuse mutable objects that you know

will not be modified. Here is a slightly more subtle and much more common example of what

not to do, involving mutable objects that are never modified once their values have been

computed:

public class Person {

private final Date birthDate;

// Other fields omitted

public Person(Date birthDate) {

this.birthDate = birthDate;

}

// DON'T DO THIS!

public boolean isBabyBoomer() {

Calendar gmtCal =

Calendar.getInstance(TimeZone.getTimeZone("GMT"));

gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);

Date boomStart = gmtCal.getTime();

gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);

Date boomEnd = gmtCal.getTime();

return birthDate.compareTo(boomStart) >= 0 &&

birthDate.compareTo(boomEnd) < 0;

}

Effective Java: Programming Language Guide

The

isBabyBoomer

method unnecessarily creates a new

Calendar

TimeZone

, and two

Date

instances each time it is invoked. The version that follows avoids this inefficiency with

a static initializer:

class Person {

private final Date birthDate;

public Person(Date birthDate) {

this.birthDate = birthDate;

}

/**

* The starting and ending dates of the baby boom.

private static final Date BOOM_START;

private static final Date BOOM_END;

static {

Calendar gmtCal =

Calendar.getInstance(TimeZone.getTimeZone("GMT"));

gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);

BOOM_START = gmtCal.getTime();

gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);

BOOM_END = gmtCal.getTime();

}

public boolean isBabyBoomer() {

return birthDate.compareTo(BOOM_START) >= 0 &&

birthDate.compareTo(BOOM_END) < 0;

}

The improved version of the Person class creates Calendar, TimeZone, and Date instances

only once, when it is initialized, instead of creating them every time

isBabyBoomer is

invoked. This results in significant performance gains if the method is invoked frequently. On

my machine, the original version takes 36,000 ms for one million invocations, while the

improved version takes 370 ms, which is one hundred times faster. Not only is performance

improved, but so is clarity. Changing

boomStart and boomEnd from local variables to final

static fields makes it clear that these dates are treated as constants, making the code more

understandable. In the interest of full disclosure, the savings from this sort of optimization

will not always be this dramatic, as

Calendar instances are particularly expensive to create.

If the

isBabyBoomer method is never invoked, the improved version of the Person class will

initialize the

BOOM_START and BOOM_END fields unnecessarily. It would be possible to

eliminate the unnecessary initializations by lazily initializing these fields (Item 48) the first

time the

isBabyBoomer

method is invoked, but it is not recommended. As is often the case

with lazy initialization, it would complicate the implementation and would be unlikely to

result in a noticeable performance improvement (Item 37).

In all of the previous examples in this item, it was obvious that the objects in question could

be reused because they were immutable. There are other situations where it is less obvious.

Consider the case of adapters [Gamma98, p. 139], also known as views. An adapter is one

object that delegates to a backing object, providing an alternative interface to the backing

Effective Java: Programming Language Guide

object. Because an adapter has no state beyond that of its backing object, there's no need to

create more than one instance of a given adapter to a given object.

For example, the

keySet method of the Map interface returns a Set view of the Map object,

consisting of all the keys in the map. Naively, it would seem that every call to

keySet

would

have to create a new

Set

instance, but every call to

keySet

on a given

Map

object may return

the same

Set

instance. Although the returned

Set

instance is typically mutable, all of the

returned objects are functionally identical: When one returned object changes, so do all the

others because they're all backed by the same

Map instance.

This item should not be misconstrued to imply that object creation is expensive and should be

avoided. On the contrary, the creation and reclamation of small objects whose constructors do

little explicit work is cheap, especially on modern JVM implementations. Creating additional

objects to enhance the clarity, simplicity, or power of a program is generally a good thing.

Conversely, avoiding object creation by maintaining your own object pool is a bad idea unless

the objects in the pool are extremely heavyweight. A prototypical example of an object that

does justify an object pool is a database connection. The cost of establishing the connection is

sufficiently high that it makes sense to reuse these objects. Generally speaking, however,

maintaining your own object pools clutters up your code, increases memory footprint, and

harms performance. Modern JVM implementations have highly optimized garbage collectors

that easily outperform such object pools on lightweight objects.

The counterpoint to this item is Item 24 on defensive copying. The present item says: “Don't

create a new object when you should reuse an existing one,” while Item 32 says: “Don't reuse

an existing object when you should create a new one.” Note that the penalty for reusing an

object when defensive copying is called for is far greater than the penalty for needlessly

creating a duplicate object. Failing to make defensive copies where required can lead to

insidious bugs and security holes; creating objects unnecessarily merely affects style and

performance.

Item 5: Eliminate obsolete object references

When you switch from a language with manual memory management, such as C or C++, to a

garbage-collected language, your job as a programmer is made much easier by the fact that

your objects are automatically reclaimed when you're through with them. It seems almost like

magic when you first experience it. It can easily lead to the impression that you don't have to

think about memory management, but this isn't quite true.

Consider the following simple stack implementation:

// Can you spot the "memory leak"?

public class Stack {

private Object[] elements;

private int size = 0;

public Stack(int initialCapacity) {

this.elements = new Object[initialCapacity];

}

剩余179页未读，继续阅读

jacknilson

粉丝: 0
资源: 2

《Effective Java》：深度解析编程语言指南

kava：DeFi for Crypto

kava-javascript-sdk:从Kava派生的用于Cosmos链的Kava JavaScript SDK

kava:自2012年以来，Kava一直在node.js和浏览器中提供精确的测试套件

kava

ilp-plugin-kava:Kava的ILP插件

The Kava Telnet Application-开源

javascript-sdk:JavaScript SDK与Kava通信

go-tools:用于Kava区块链的Golang工具集合

kava:kʌvə - 从当前的 mpd 专辑封面创建壁纸

Kava: 自动将MPD播放的专辑封面转换为壁纸

最新资源