@(EffecitiveJava)[类设计|JAVA基础]
应用场景：
当我们准备实现一个具有特殊约束条件类的时候，假设类的客户端会尽其所能的破坏这个类的约束条件，因此我们必须保护性设计程序。
扩展：
JAVA是一门安全的语言。这就意味着，它对缓冲区溢出、数组越界、非法指针以及其它的内存破坏错误都自动免疫，而这些错误却困扰着诸如C和C++这样的不安全的语言。在一门安全的语言中，可以确切的知道，无论系统的其他部分发生什么事，这些类的约束都可以保持为真。对于那些“把内存当做一个巨大数组看待”的语言来说，这是不可能的。
规范已经注意事项
- 对于构造器的每个可变参数进行保护性拷贝
如上图所示，检查参数的合法性（约束）是在保护性拷贝之后进行的。而且参数的合法性的检查是针对保护性拷贝之后的对象，而不是针对原始对象。
这样做是为了避免危险阶段来自另外一个线程的修改参数。危险阶段指的是检查参数开始，直至保护性拷贝参数之间的时间。在计算机安全社区中，这段时间被称为TOC、TOU（Time-Of-Use,Time-Of-Check)。
- 对于参数类型可以被不可信任类子类化的参数，请不要使用clone方法进行保护性拷贝，文摘如下：
原因：不能保证clone方法返回类一定是X类的对象，由于JAVA的向上转型特性，返回的可能是出于恶意的目的而设计的不可信子类的实例。
- 当X类提供了可变内部成员的访问能力时，该访问返回的应该是可变内部域的保护性拷贝。
总结：
保护性拷贝，不仅仅适用于不可变类。当编写构造器或方法时，如果它要允许客户提供的对象进入到内部数据中，则有必要考虑一下，客户端提供的对象是否可能是有变的。如果是，就要考虑到你的类是否能容忍对象进入数据结构之后发生变化。如果答案是否定的，那么就必须使用保护性拷贝，并且让保护性拷贝之后的对象而不是原始对象进入到类的内部。
保护性拷贝可能会带来性能损失，我觉得这是对的。类的拷贝明显会增加一个方法执行的时间成本。原文说，这种说法并不总是对的，但并没有指出这种情况，我想了想，也没想到。
保护性拷贝是可以被代替的。如果某些情况下，拷贝成本收到限制，并且类信任它的客户端不会不恰当的修改组件，可以在文档中显示声明不得修改收到影响的组件，以此代替保护性拷贝。
