The Java™ Tutorials — Concurrency ：A Strategy for Defining Immutable Objects 一个定义不可变对象的策略

The Java™ Tutorials — Concurrency ：A Strategy for Defining Immutable Objects 一个定义不可变对象的策略

原文地址：https://docs.oracle.com/javase/tutorial/essential/concurrency/imstrat.html

关键点

一个定义不可变对象的策略：
不要提供setter方法，也就是指那些可以改变字段或字段所引用对象的方法。
把所有字段标记为final和private
不要允许子类覆写这些方法。最简单的方式就是讲类声明为final。一个更复杂的方式是，让构造器私有，并利用工厂方法创建实例
如果实例字段包含了对可变对象的引用，不要允许对这些对象的改变： 
不要提供可改变这些可变对象的方法
不要共享这些对可变对象的引用。坚决不要将这些引用存储到类外，也不要存储到由构造器传入的变量中；如有必要，创建副本，并将引用存储到副本之中。同样的，必要情况下，创建你的内部可变变量的引用副本， 以避免返回你方法中原来的对象。

全文翻译

The following rules define a simple strategy for creating immutable objects. Not all classes documented as “immutable” follow these rules. This does not necessarily mean the creators of these classes were sloppy — they may have good reason for believing that
instances of their classes never change after construction. However, such strategies require sophisticated analysis and are not for beginners.
Don’t provide “setter” methods — methods that modify fields or objects referred to by fields.
Make all fields final and private.
Don’t allow subclasses to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in
factory methods.
If the instance fields include references to mutable objects, don’t allow those objects to be changed: 
Don’t provide methods that modify the mutable objects.
Don’t share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create
copies of your internal mutable objects when necessary to avoid returning the originals in your methods.

下面的规则定义了一种创建不可变对象的简单策略。并非所有的被标记为“不可变”的类都需要遵守此规则。这并非一定意味着这些类的创建者都是马马虎虎的——他们也许有很好的理由相信他们类的实例在构造出后永远不会被改动。然而，这样的策略需要复杂的分析，这并不适用于初学者。
不要提供setter方法，也就是指那些可以改变字段或字段所引用对象的方法。
把所有字段标记为final和private
不要允许子类覆写这些方法。最简单的方式就是讲类声明为final。一个更复杂的方式是，让构造器私有，并利用工厂方法创建实例
如果实例字段包含了对可变对象的引用，不要允许对这些对象的改变： 
不要提供可改变这些可变对象的方法
不要共享这些对可变对象的引用。坚决不要将这些引用存储到类外，也不要存储到由构造器传入的变量中；如有必要，创建副本，并将引用存储到副本之中。同样的，必要情况下，创建你的内部可变变量的引用副本， 以避免返回你方法中原来的对象。

Applying this strategy to SynchronizedRGB results in the following steps:
There are two setter methods in this class. The first one, set, arbitrarily transforms the object, and has no place in an immutable version of the class. The second one, invert, can be adapted by having
it create a new object instead of modifying the existing one.
All fields are already private; they are further qualified as final.
The class itself is declared final.
Only one field refers to an object, and that object is itself immutable. Therefore, no safeguards against changing the state of “contained” mutable objects are necessary.

将此策略应用到SynchronizedRGB中，你就需要做如下步骤：
在类中有两个Setter方法。第一个，也就是set方法，会随意地转换对象，它不应该在此不可变版本中存在。第二个，invert方法，可以用创建新对象的方法而非修改现存对象的方式修改。
所有的字段都已经为private，它们需要进一步处理为final
把这个类本身定义为final
只有一个字段引用了一个对象，而这个对象本身就是不可变对象。因此，也就无需那些防止内内置可变对象被修改的策略了。

After these changes, we have ImmutableRGB:

做了这些更改后，我们便有了ImmutableRGB类：

final public class ImmutableRGB {

// Values must be between 0 and 255.
final private int red;
final private int green;
final private int blue;
final private String name;

private void check(int red,
int green,
int blue) {
if (red < 0 || red > 255
|| green < 0 || green > 255
|| blue < 0 || blue > 255) {
throw new IllegalArgumentException();
}
}

public ImmutableRGB(int red,
int green,
int blue,
String name) {
check(red, green, blue);
this.red = red;
this.green = green;
this.blue = blue;
this.name = name;
}

public int getRGB() {
return ((red << 16) | (green << 8) | blue);
}

public String getName() {
return name;
}

public ImmutableRGB invert() {
return new ImmutableRGB(255 - red,
255 - green,
255 - blue,
"Inverse of " + name);
}
}