Effective Java 3rd 阅读笔记

发生错误之后应该尽快检测出错误
尽量让错误/警告在编译的时候就出现
尽量异常，不要试图隐藏错误

- [第二章：创建和销毁对象](#第二章创建和销毁对象)
    - [第1条：用静态工厂方法代替构造器](#第1条用静态工厂方法代替构造器)
    - [第2条：遇到多个构造器参数时要考虑使用构建器](#第2条遇到多个构造器参数时要考虑使用构建器)
    - [第3条：用私有构造器或者枚举类型强化Singleton属性](#第3条用私有构造器或者枚举类型强化singleton属性)
    - [第4条：通过私有构造器强化不可实例化的能力](#第4条通过私有构造器强化不可实例化的能力)
    - [第5条：优先考虑依赖注入来引用资源](#第5条优先考虑依赖注入来引用资源)
    - [第6条：避免创建不必要的对象](#第6条避免创建不必要的对象)
    - [第7条 消除过期对象的引用](#第7条-消除过期对象的引用)
    - [第8条 避免使用终结方法和清除方法](#第8条-避免使用终结方法和清除方法)
    - [第9条 try-with-resources优先于try-finally](#第9条-try-with-resources优先于try-finally)
- [第三章 对于所有对象都通用的方法](#第三章-对于所有对象都通用的方法)
    - [第10条 覆盖equals时请遵守通用约定](#第10条-覆盖equals时请遵守通用约定)
    - [第11条 覆盖equals时总要覆盖hashCode](#第11条-覆盖equals时总要覆盖hashcode)
    - [第12条 始终要覆盖toString](#第12条-始终要覆盖tostring)
    - [第13条 谨慎地覆盖clone](#第13条-谨慎地覆盖clone)
    - [第14条 考虑实现Comparable接口](#第14条-考虑实现comparable接口)
- [第四章 类和接口](#第四章-类和接口)
    - [第15条 使类和成员的可访问性最小化](#第15条-使类和成员的可访问性最小化)
    - [第16条 要在公有类而非公有域中使用访问方法](#第16条-要在公有类而非公有域中使用访问方法)
    - [第17条 使可变性最小化](#第17条-使可变性最小化)
    - [第18条 复合优先于继承](#第18条-复合优先于继承)
    - [第19条 要么设计继承并提供文档说明，要么禁止继承](#第19条-要么设计继承并提供文档说明要么禁止继承)
    - [第20条 接口优于抽象类](#第20条-接口优于抽象类)
    - [第21条 为后代设计接口](#第21条-为后代设计接口)
    - [第22条 接口只用于定义类型](#第22条-接口只用于定义类型)
    - [第23条 类层次优于标签类](#第23条-类层次优于标签类)
    - [第24条 静态成员类优于非静态成员类](#第24条-静态成员类优于非静态成员类)
    - [第25条 限制源文件为单个顶级类](#第25条-限制源文件为单个顶级类)
- [第五章 泛型](#第五章-泛型)
    - [第26条 请不要使用原生态类型](#第26条-请不要使用原生态类型)
    - [第27条 消除非受检的警告](#第27条-消除非受检的警告)
    - [第28条 列表优于数组](#第28条-列表优于数组)
    - [第29条 优先考虑泛型](#第29条-优先考虑泛型)
    - [第30条 优先考虑泛型方法](#第30条-优先考虑泛型方法)
    - [第31条 利用有限制通配符来提升API的灵活性](#第31条-利用有限制通配符来提升api的灵活性)
    - [第32条 谨慎并用泛型和可变参数](#第32条-谨慎并用泛型和可变参数)
    - [第33条 优先考虑类型安全的异构容器](#第33条-优先考虑类型安全的异构容器)
- [第六章 枚举和注解](#第六章-枚举和注解)
    - [第34条 用enum代替int常量](#第34条-用enum代替int常量)
    - [第35条 用实例域代替序数](#第35条-用实例域代替序数)
    - [第36条 用EnumSet代替位域](#第36条-用enumset代替位域)
    - [第37条 用EnumMap代替序数索引](#第37条-用enummap代替序数索引)
    - [第38条 用接口模拟可扩展的枚举](#第38条-用接口模拟可扩展的枚举)
    - [第39条 注解优先于命名模式](#第39条-注解优先于命名模式)
    - [第40条 坚持使用Override注解](#第40条-坚持使用override注解)
    - [第41条 用标记接口定义类型](#第41条-用标记接口定义类型)
- [第七章 Lambda和Stream](#第七章-lambda和stream)
    - [第42条 Lambda优先于匿名类](#第42条-lambda优先于匿名类)
    - [第43条 方法引用优先于Lambda](#第43条-方法引用优先于lambda)
    - [第44条 坚持使用标准的函数接口](#第44条-坚持使用标准的函数接口)
    - [第45条 谨慎使用Stream](#第45条-谨慎使用stream)
    - [第46条 优先选择Stream中无副作用的函数](#第46条-优先选择stream中无副作用的函数)
    - [第47条 Stream要优先用Collection作为返回类型](#第47条-stream要优先用collection作为返回类型)
    - [第48条 谨慎使用Stream并行](#第48条-谨慎使用stream并行)
- [第八章 方法](#第八章-方法)
    - [第49条 检查参数的有效性](#第49条-检查参数的有效性)
    - [第50条 必要时进行保护性拷贝](#第50条-必要时进行保护性拷贝)
    - [第51条 谨慎设计方法签名](#第51条-谨慎设计方法签名)
    - [第52条 慎用重载](#第52条-慎用重载)
    - [第53条 慎用可变参数](#第53条-慎用可变参数)
    - [第54条 返回零长度的数组或集合，而不是null](#第54条-返回零长度的数组或集合而不是null)
    - [第55条 谨慎返回optional](#第55条-谨慎返回optional)
    - [第56条 为所有导出的API元素编写文档注释](#第56条-为所有导出的api元素编写文档注释)
- [第九章 通用编程](#第九章-通用编程)
    - [第57条 将局部变量的作用域最小化](#第57条-将局部变量的作用域最小化)
    - [第58条 for-each循环优先于传统的for循环](#第58条-for-each循环优先于传统的for循环)
    - [第59条 了解和使用类库](#第59条-了解和使用类库)
    - [第60条 如果需要精确的答案，请避免使用float和double](#第60条-如果需要精确的答案请避免使用float和double)
    - [第61条 基本类型优先于装箱基本类型](#第61条-基本类型优先于装箱基本类型)
    - [第62条 如果其他类型更合适，则尽量避免使用字符串](#第62条-如果其他类型更合适则尽量避免使用字符串)
    - [第63条 了解字符串连接的性能](#第63条-了解字符串连接的性能)
    - [第64条 通过接口引用对象](#第64条-通过接口引用对象)
    - [第65条 接口优先于反射机制](#第65条-接口优先于反射机制)
    - [第66条 谨慎地使用本地方法](#第66条-谨慎地使用本地方法)
    - [第67条 谨慎地进行优化](#第67条-谨慎地进行优化)
    - [第68条 遵守普遍接受的命名惯例](#第68条-遵守普遍接受的命名惯例)
- [第十章 异常](#第十章-异常)
    - [第69条 只针对异常的情况才使用异常](#第69条-只针对异常的情况才使用异常)
    - [第70条 对可恢复的情况使用受检异常，对编程错误使用运行时异常](#第70条-对可恢复的情况使用受检异常对编程错误使用运行时异常)
    - [第71条 避免不必要地使用受检异常](#第71条-避免不必要地使用受检异常)
    - [第72条 优先使用标准的异常](#第72条-优先使用标准的异常)
    - [第73条 抛出与抽象对应的异常](#第73条-抛出与抽象对应的异常)
    - [第74条 每个方法抛出的所有异常都要建立文档](#第74条-每个方法抛出的所有异常都要建立文档)
    - [第75条 在细节消息中包含失败-捕获信息](#第75条-在细节消息中包含失败-捕获信息)
    - [第76条 努力使失败保持原子性](#第76条-努力使失败保持原子性)
    - [第77条 不要忽略异常](#第77条-不要忽略异常)
- [第十一章 并发](#第十一章-并发)
    - [第78条 同步访问共享的可变数据](#第78条-同步访问共享的可变数据)
    - [第79条 避免过度同步](#第79条-避免过度同步)
    - [第80条 executor， task和stream优先于线程](#第80条-executor-task和stream优先于线程)
    - [第81条 并发工具优先于wait和notify](#第81条-并发工具优先于wait和notify)
    - [第82条 线程安全性的文档化](#第82条-线程安全性的文档化)
    - [第83条 慎用延迟初始化](#第83条-慎用延迟初始化)
    - [第84条 不要依赖于线程调度器](#第84条-不要依赖于线程调度器)
- [第十二章 序列化](#第十二章-序列化)
    - [第85条 其他方法优先于Java序列化](#第85条-其他方法优先于java序列化)
    - [第86条 谨慎地实现Serializable接口](#第86条-谨慎地实现serializable接口)
    - [第87条 考虑使用自定义的序列化形式](#第87条-考虑使用自定义的序列化形式)
    - [第88条 保护性地编写readObject方法](#第88条-保护性地编写readobject方法)
    - [第89条 对于实例控制，枚举类型优先于readResolve](#第89条-对于实例控制枚举类型优先于readresolve)
    - [第90条 考虑用序列化代理代替序列化实例](#第90条-考虑用序列化代理代替序列化实例)

第二章：创建和销毁对象

第1条：用静态工厂方法代替构造器

• 静态工厂方法相比构造器的优势：
  前四点比较容易理解，第5点：静态工厂方法返回的对象所属的类，在编写包含该静态工厂方法的类时可以不存在。后文又提到服务提供者框架。服务提供者框架类图如图所示。
  

典型的服务提供者框架应用JDBC。

• 静态工厂方法的缺点：
  1. 类如果不含公有的或者受保护的构造器，就不能被子类实例化。这一点可以通过复合来解决。
  2. 程序员很难发现他们。因此，需要遵守标准的命名习惯。
• 常见命名:
  • from 类型转换方法
  • of 聚合方法
  • valueof
  • instance/getInstance
  • create/newInstance
  • getTYPE: 例如：Files.getFileStore(path);
  • newTYPE: 例如：Files.newBufferedReader(path);
  • TYPE: 例如 Collections.list(..);

第2条：遇到多个构造器参数时要考虑使用构建器

• 类多个属性时，构造对象有三种选择：
  1. 重叠构造器：客户端代码很难编写
  2. JavaBeans模式：构造过程被分到了几个调用中，在构造过程中，JavaBean可能处于不一致的状态。JavaBeans模式使得把类做成不可变性的可能性不复存在。
  3. 建造者(Builder)模式：如果类的构造器或者静态工厂中具有多个参数，设计这种类，Builder模式就是一种不错的选择。

/**建造者模式创建对象样例*/
NutritionFacts fact = new NutritionFacts.Builder(140, 40).calories(100).sodium(35).carbohydrate(27).build();
//---------------------------------
public class NutritionFacts {
	private final int servingSize;
	private final int servings;
	private final int calories;
	private final int fat;
	private final int sodium;
	private final int carbohydrate;

	public static class Builder {
		private final int servingSize;
		private final int servings;

		private int calories = 0;
		private int fat = 0;
		private int sodium = 0;
		private int carbohydrate = 0;

		public Builder(int servingSize, int servings) {
			this.servingSize = servingSize;
			this.servings = servings;
		}

		public Builder calories(int val) {
			calories = val;
			return this;
		}

		public Builder fat(int val) {
			fat = val;
			return this;
		}

		public Builder sodium(int val) {
			sodium = val;
			return this;
		}

		public Builder carbohydrate(int val) {
			carbohydrate = val;
			return this;
		}

		public NutritionFacts build() {
			return new NutritionFacts(this);
		}
	}

	private NutritionFacts(Builder builder) {
		servingSize = builder.servingSize;
		servings = builder.servings;
		calories = builder.calories;
		fat = builder.fat;
		sodium = builder.sodium;
		carbohydrate = builder.carbohydrate;
	}
}

第3条：用私有构造器或者枚举类型强化Singleton属性

• 单元素的枚举类型经常成为实现Singleton的最佳方法。
  • 规避反射攻击
  • 规避序列化问题
  • 博客 为什么要用枚举实现单例模式（避免反射、序列化问题）

public enum SingletonEnum {
	INSTANCE;
	private String content;
  private SingletonEnum() {}
	public String getContent() {
      return content;
  }
  public void setContent(String content) {
      this.content = content;
  }

	public SingletonEnum getInstance() {
		return INSTANCE;
	}
}

第4条：通过私有构造器强化不可实例化的能力

• 让这个类包含一个私有构造器，它就不能被实例化

public class UtilityClass {
	//suppress default constructor for noninstantiability
	//抑制默认构造函数的非实例化
	private UtilityClass() {
		throw new AssertionError();
	}
}

第5条：优先考虑依赖注入来引用资源

• 静态工具类和Singleton类不适合与需要应用底层资源的类。
  • 笨拙，易出错，无法并行工作
• 需要能够支持类的多个实例，每一个实例都使用客户端指定的资源。当创建一个新的实例时，就将该资源传到构造器中。依赖注入的对象资源具有不可变性。
• 总而言之，不要用Singleton和静态工具类来实现依赖一个或多个底层资源的类，且该资源的行为会影响到该类的行为；也不要直接用这个类来创建这些资源。这个实践就被称作依赖注入，它极大地提升了类的灵活性、可重用性和可测试性。

/**
 * 	拼写检查器
 * @author qiweiwei
 * @date 2019年7月1日-下午4:47:02
 * @describle
 *
 */
public class SpellChecker {
	private final String dictionary;
	public SpellChecker(String dictionary) {
		this.dictionary = Objects.requireNonNull(dictionary);
	}
	public boolean isVlid(String word) {
		//TODO
		return false;
	}
	public List<String> suggestions(String typo) {
		//TODO
		return null;
	}
}

第6条：避免创建不必要的对象

• 虽然String.matches方法最易于查看一个字符串是否与正则表达式相匹配，但并不适合在注重性能的情形中重复使用。问题在于，它在内部为正则表达式创建了一个Pattern实例，却只用了一次，之后就可以进行垃圾回收了。创建Pattern实例的成本很高，因为需要将正则表达式编译成一个有限状态机。

public static Map<String, Pattern> patterns = new HashMap<String, Pattern>();

public static Pattern getPattern(String regex) {
  if (patterns.containsKey(regex)) {
    return patterns.get(regex);
  } else {
    Pattern pattern = Pattern.compile(regex);
    patterns.put(regex, pattern);
    return pattern;
  }
}

• 自动装箱使得基本类型和装箱基本类型之间的差别变得模糊起来，但是并没有完全消除。他们在语义上有着微妙的差别，在性能上有着比较明显的差别。
• 要优先使用基本类型而不是装箱基本类型，要当心无意识的自动装箱。
• 不要错误的认为“创建对象的代价非常昂贵，我们应该要尽可能地避免创建对象”，相反，由于小对象的构造器只做很少量的显示工作，所以小对象的创建和回收动作是非常廉价的，特别是在现代的JVM实现上更是如此。通过创建附加的对象，提升程序的清晰性、简洁性和功能性，这通常是件好事。
• 反之，通过维护自己的对象池来避免创建对象并不是一种好的做法，除非池中的对象是非常重要级的。正确使用对象池的典型对象示例就是数据库连接池。

第7条 消除过期对象的引用

• 在支持垃圾回收的语言中，内存泄露是很隐蔽的。如果一个对象引用被无意识地保留下来了，那么垃圾回收机制不仅不会处理这个对象，而且也不会处理被这个对象所引用的所有其他对象。
• 清空过期引用的另一个好处是，如果它们以后又被错误地接触引用，程序就会立即抛出NullPointerException异常，而不是悄悄地错误运行下去。
• 清空对象引用应该是一种例外，而不是一种规范行为。
• 消除过期引用最好的方法是让包含该引用的变量结束其生命周期。如果你是在紧凑的作用域范围内定义每一个变量，这种情形就会自然而然地发生。
• 一般来说，只要类是自己管理内存，程序员就应该警惕内存泄露问题。（栈Stack类是自己管理内存）
• 内存泄露的另一个常见来源是缓存。WeakHashMap：只要在缓存之外存在对某个项的键的引用，该项就有意义，那么就可以用WeakHashMap代表缓存；当缓存中的项过期之后，它们就会自动被删除。记住只有当所要的缓存项的生命周期是由该键的外部引用而不是由值决定时，WeakHashMap才有用处。“缓存项的声明周期是否有意义”并不是很容易确定。随着时间的推移，其中的项会变得越来越没有价值。在这种情况下，缓存应该时不时地清楚掉没用的项。
• 内存泄露的第三个常见来源是监听器和其他回调。如果你实现了一个API，客户端在这个API中注册回调，却没有显式地取消注册，那么除非你采取这些动作，否则它们就会不断地堆积起来。确保回调立即被垃圾回收的最佳方法是只保存它们的弱引用，例如，只将它们保存成WeakHashMap中的键。
• 内存泄露问题通常不会表现成明显的失败，往往只有通过仔细检查代码，或者借助于Heap剖析工具(Heap Profiler)才能发现内存泄露问题。

第8条 避免使用终结方法和清除方法

• 终结方法(finalizer)通常是不可预测的，也是很危险的，一般情况下是不必要的。使用终结方法会导致行为不稳定、性能降低，以及可移植性问题。
• 在Java9中，用清除方法代替了终结方法。清除方法没有终结方法那么危险，但仍然是不可预测、运行缓慢，一般情况下也是不必要的。
• 终结方法和清除方法的缺点在于不能保证会被及时执行。注重时间的任务不应该由终结方法或者清楚方法来完成。
• 永远不应该依赖终结方法或者清除方法来更新重要的持久状态。
• 使用终结方法的另一个问题是：如果忽略在终结过程中被抛出来的未被捕获的异常，该对象的终结过程也会终止。
• 使用终结方法和清除方法有一个非常严重的性能损失。
• 终结方法有一个严重的安全问题：它们为终结方法共计(finalizer attack)打开了类的大门。终结方法攻击背后的思想很简单：如果从构造器或者它的序列化对等体抛出异常，恶意子类的终结方法就可以在构造了一部分的应该已经半途夭折的对象上运行。从构造器抛出的异常，应该足以放置对象继续存在；有了终结方法的存在，这一点就做不到了。为了防止非final类受到终结方法攻击，要编写一个空的final的finalize方法。
• 如果类的对象中封装的资源确实需要终止，只需让类实现AutoCloseable，并要求其客户端在每个实例不再需要的时候调用close方法。
• 总而言之，除非是作为安全网，或者是为了终止非关键的本地资源，否则请不要使用清除方法，对于在Java9之前的发行版本，则尽量不要使用终结方法。

第9条 try-with-resources优先于try-finally

• try-finally语句存在些许不足，因为在try和finally块中的代码，都会抛出异常。
• Java7引入try-with-resource。要使用这个构造的资源，必须先实现AutoCloseable接口，其中包含了单个返回void的close方法。

try (ObjectOutputStream outputStream = new  ObjectOutputStream(new FileOutputStream("D://singletonEnum.obj"))) {
			outputStream.writeObject(s);
			outputStream.flush();
}

try (ObjectInputStream inputStream2 = new ObjectInputStream(new FileInputStream("D://singletonEnum.obj"))){
			SingletonEnum s1 = (SingletonEnum)inputStream2.readObject();
}

第三章 对于所有对象都通用的方法

本章将讲述何时以及如何覆盖这些非final的Object方法。本章也对Comparable.compareTo方法进行讨论，因为它具有类似的特征。

第10条 覆盖equals时请遵守通用约定

• 不宜覆盖equals方法的情形：
  • 类的每个实例本质上都是唯一的，对于代表活动实体而不是值的类来说，确实如此
  • 类没有必要提供“逻辑相等”的测试功能
  • 超类已经覆盖了equals，超类的行为对于这个类也是合适的
  • 类是私有的，或者是包级私有的，可以确定它的equals方法永远不会被调用

   @Override
public boolean equals(Object o) {
	//method is never called
	throw new AssertionError();
}

• 如果类具有自己特有的“逻辑相等”(logitical equality)概念，而且超类还没有覆盖equals。这样做也使得这个类的实例可以被用作映射表(map)的键，或者集合(set)的元素，使映射或者集合表现出预期的行为。
• 有一种“值”不需要覆盖equals方法，即用实例受控确保“每个值至多只存在一个对象”的类。枚举类型就属于这种类。对于这样的类而言，逻辑相同与对象等同是一回事。
• equals约定：等价关系
  • 自反性(reflexive):对于任何非null的引用值x, x.equals(x)必须返回true。
  • 对称性(symmetric):对于任何非null的引用值x和y，当且仅当y.equals(x)返回true时，x.equals必须返回true。
  • 传递性(transitive):对于任何非null的引用值x, y和z，如果x.equals(y)返回true，并且y.equals(z)也返回true, 那么x.equals(z)也必须返回true。
  • 一致性(consistent):对于任何非null的引用值x和y，只要equals的比较操作在对象中所用的信息没有被修改，多次调用x.equals(y)就会移植地返回true，或者一致地返回false。
  • 非空性：对于任何非null的引用值x，x.equals(null)必须返回false。
• 我们无法在扩展可实例化的类的同时，既增加新的值组件，同时又保留equals约定，除非愿意放弃面向对象的抽象所带来的优势。
  • 一种权益之计：复合优先于继承

/**
* 复合优先于继承
*/
public class ColorPoint {

	private final Point point;
	private final String color;

	public ColorPoint(int x, int y, String color) {
		point = new Point(x, y);
		this.color = Objects.requireNonNull(color);
	}

	public Point asPoint() {
		return point;
	}

	@Override
	public boolean equals(Object object) {
		if (!(object instanceof ColorPoint)) {
			return false;
		}
		ColorPoint cp = (ColorPoint)object;
		return cp.point.equals(point) && cp.color.equals(color);
	}
}

• 高质量equals方法的诀窍：
  • 使用 “==” 操作符检查“参数是否为这个对象的引用”，如果是，则返回true。
  • 使用 “instanceof” 操作符检查“参数是否为正确的类型”：一般情况下是指equals方法所在的那个类，某些情况下是指该类所实现的某个接口，如Set， List， Map，Map.Entry。
  • 把参数转换为正确的类型
  • 对于该类中的每个“关键”域，检查参数中的域是否与该对象中对应的域相匹配。
  • 对于既不是float也不是double类型的基本类型域，可以使用==操作符进行比较；对于对象引用域，可以递归地调用equals方法；对于float域，可以使用静态Float.compare(float, float)方法；对于double域，则使用Double.compare(double, double)。对于数组域，则要把以上这些指导原则应用到每一个元素上。如果数组域中的每个元素都很重要，就可以使用其中一个Arrays.equals方法；有些对象引用域包含null可能是合法的，则使用Objects.equals(Object, Object)来检查这类域的等同性；
  • 为了获取最佳性能，应该最先比较最有可能不一致的域，或者是开销最低的域
• 在编写完equals方法之后，应该问自己三个问题：它是否是对称的，传递的、一致的？
• 覆盖equals时总要覆盖hashCode
• 不要企图让equals方法过于智能。例如：File类不应试图把指向同一个文件的符号链接当作相等的对象来看待。
• 不要将equals声明中的Object对象替换为其他的类型。
• 代替手工编写和测试这些方法的最佳途径，是使用Google开源的AutoValue框架，它会自动替你生成这些方法，通过类中的单个注解(@AutoValue)就能触发（生成的.java文件在class路径下）。IDE也有工具可以生成equals和hashCode方法，但得到的源代码比使用Auto-Value的更加冗长，可读性也更差，它无法追踪类中的变化，因此需要进行测试。
• 总而言之，不要轻易覆盖equals方法，除非迫不得已。

第11条 覆盖equals时总要覆盖hashCode

• 在每个覆盖了equals方法的类中，都必须覆盖hashCode方法
• 约定：
  • 只要对象的equals方法的比较操作所用到的信息没有被修改，那么对同一个对象的多次调用，hashCode方法都必须始终返回同一个值
  • equals(Object)是相等的，那么hashCode必须相同；即 相等的对象必须具有相等的散列码
  • 如果equals不等，不要求hashCode不同；但是给不相等的对象产生不同的整数结果，有可能提高散列表的性能
  • 如果一个类是不可变的，并且计算散列码的开销也比较大，就应该考虑把散列码缓存在对象内部，而不是每次请求的时候都重新计算散列码。或“延迟初始化”散列码，即一直到hashCode被第一次调用的时候才初始化。
  • 不要试图从散列码计算中排除掉一个对象的关键域来提高性能。
  • 不要对hashCode方法的返回值做出具体的规定，因此客户端无法理所当然地依赖它，这样可以为修改提供灵活性。

第12条 始终要覆盖toString

• 提供好的toString实现可以使类用起来更加舒适，使用了这个类的系统也更易于调试。
• toString方法应该返回对象中包含的所有值得关注的信息，或者对象太大时应返回摘要信息。
• 无论是否决定指定格式，都应该在文档中明确地表明你的意图
• 总而言之，toString方法应该以美观的格式返回一个关于对象的简洁、有用的描述。

第13条 谨慎地覆盖clone

• 事实上，实现Cloneable接口的类是为了提供一个功能适当的公有clone方法。
• 不可变的类用于都不应该提供clone方法
• 实际上，clone方法就是另一个构造器；必须确保它不会伤害到原始的对象，并确保正确地创建被克隆对象中的约束条件
• Cloneable架构与引用可变对象的final域的正常用法是不相兼容的。
• 克隆复杂对象的一种方法：先调用super.clone方法，然后把结果对象中的所有域都设置成它们的初始状态，然后调用高层的方法来重新产生对象的状态。
• clone方法不应该在构造的过程中调用可以覆盖的方法（子类覆盖方法有可能修改对象中的状态）
• 公有的clone方法应该省略throws声明
• 如果你编写线程安全的类准备实现Cloneable接口，要记住它的clone方法必须得到严格的同步，就像其他任何方法一样，即 synchronized clone()。
• 简而言之，所有实现Cloneable接口的类都应该覆盖clone方法，并且是公有的方法，它的返回类型为类本身。该方法应该先调用super.clone， 然后修正任何需要修正的域。
• 对象拷贝的更好方法是提供一个拷贝构造器或拷贝工厂
• 数组例外，最好利用clone方法复制数组

public Yum(Yum yum) {...}

public static Yum newInstance(Yum yum) {...}

第14条 考虑实现Comparable接口

• 违反compareTo约定的类会破坏其他依赖于比较关系的类，例如有序集合类TreeSet和TreeMap，以及工具类Collections和Arrays，它们内部包含有搜索和排序算法。
• 同equals一样，无法在用新的值组件扩展可实例化的类时，同时保持compareTo约定，除非愿意放弃面向对象的抽象优势
• 强烈建议(x.compareTo(y) == 0) == (x.equals(y))，但这并非绝对必要。
  • 例如，BigDecimal，它的compareTo与equals不一致，new BigDecimal(“1.0”)与new BigDecimal(“1.00”)通过equals比较是不等的，而通过compareTo比较是相等的。若使用HashSet，会保存两个元素。而使用TreeSet则只会包含一个元素。
• java7版本中，已经在Java的所有装箱基本类型的类中增加了静态的compare方法。
• 从最关键的域开始，逐步比较所有的重要域。如果某个域的比较产生了非零的结果，则整个比较操作结束，并返回该结果。
• 总而言之，每当实现一个对排序敏感的类时，都应该让这个类实现Comparable接口，以便其实例可以轻松地被分类、搜索，以及用在基于比较的集合中。在compareTo方法中比较域值时，都要避免使用<和>操作符，而应该在装箱基本类型的类中使用静态的compare方法，或者在Comparator接口中使用比较器构造方法。

第四章 类和接口

第15条 使类和成员的可访问性最小化

• 信息隐藏/封装：区分一个组件设计的好不好，唯一重要的因素在于，它对于外部的其他组件而言，是否隐藏了其内部数据和其他实现细节。
• 规则：尽可能地使每个类或者成员不被外界访问。
• 公有类是包API的一部分，包级私有的顶层类则已经是这个包的实现的一部分。
• 公有类的实例域决不能是公有的。包含公有可变域的类通常并不是线程安全的。
• 长度非零的数组总是可变的，所以让类具有公有的静态final数组域，或者返回这种域的访问方法，这是错误的。(安全漏洞的常见根源)
• 总而言之，应该始终尽可能（合理）地降低程序元素的可访问性。

//Potential security hole! 潜在的安全漏洞
public static final Thing[] VALUES = {...};

//修正方法1：
private static final Thing[] PRIVATE_VALUES = {...};
public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

//修正方法2：
private static final Thing[] PRIVATE_VALUES = {...}
public static final Thing[] value() {
	return PRIVATE_VALUES.clone();
}

第16条 要在公有类而非公有域中使用访问方法

• 如果类可以在它所在的包之外进行访问，就提供访问方法，以保留将来改变该类的内部表示法的灵活性。
• 如果类是包级私有的，或者是私有的嵌套类，直接暴露它的数据域并没有本质的错误。
• 简而言之，公有类永远都不应该暴露可变的域。

第17条 使可变性最小化

• 不可变类是指其实例不能被修改的类。
• 使类成为不可变类，要遵循下面5条规则：
  • 不要提供任何会修改对象状态的方法（也称为设值方法）
  • 保证类不会被扩展：一般做法是声明这个类成为final的
  • 声明所有的域都是final的
  • 声明所有的域都为私有的
  • 确保对于任何可变组件的互斥访问：如果类具有指向可变对象的域，则必须确保该类的客户端无法获得指向这些对象的引用。在构造器、访问方法和readObject方法中请使用保护性拷贝技术。
• 不可变对象本质上是线程安全的，它们不要求同步，可以被自由地共享。
• 不可变类可以提供一些静态工厂，它们把频繁被请求的实例缓存起来，从而当现有实例可以符合请求的时候，就不必创建新的实例。
• 不需要，也不应该为不可变类提供clone方法或者拷贝构造器。
• 不仅可以共享不可变对象，甚至也可以共享它们的内部信息。
• 不可变对象为其他对象提供了大量的构件，无论是可变的还是不可变的对象：这条原则的一种特例在于，不可变对象构成了大量的映射建和集合元素。
• 不可变对象无偿地提供了失败的原子性。
• 不可变类真正唯一的缺点是，对于每个不同的值都需要一个单独的对象。创建这些对象的代价可能很高，特别是大型的对象。
• 如果能够精确地预测出客户端将要在不可变的类上执行哪些复杂的多阶段操作，这种包级私有的可变配套类的方法就可以工作得很好。如果无法预测，最好的方法是提供一个公有的可变配套类。例如String的配套StringBuilder。
• 不可变的类变成final的另一种方法就是，让类的所有构造器都变成私有的或者包级私有的，并且添加公有的静态工厂来代替公有的构造器。这种方法还使得有可能通过改善静态工厂的对象缓存能力，在后续的发行版本中改进该类的性能。
• 不可变类：没有一个方法能够对对象的状态产生外部可见的改变，然后许多不可变类拥有一个或者多个非final的域，它们在第一次被请求执行这些计算的时候，把一些开销昂贵的计算结果缓存在这些域中。
• 如果你选择让自己的不可变类实现Serializable接口，并且它包含一个或多个指向可变对象的域，就必须提供一个显示的readObject或者readResolve方法，或者使用ObjectOutputStream.writeUnshared和ObjectInputStream.readUnshared方法，即便默认的序列化形式是可以接受的，也是如此。否则，攻击者可能从不可变的类创建可变的实例。
• 除非有很好的理由要让类成为可变的类，否则它就应该是不可变的。
• 如果类不能被做成不可变的，仍然应该尽可能地显示它的可变性。
• 除非有令人信服的理由要使域变成是非final的，否则要使每个域都是private final的。
• 构造器应该创建完全初始化的对象，并建立起所有的约束关系。不要在构造器或者静态工厂之外再提供公有的初始化方法，除非有令人信服的理由必须这么做。同样的，也不应该提供“重新初始化”方法。

public class Complex {
	private final double re;
	private final double im;

	private Complex(double re, double im) {
		this.re = re;
		this.im = im;
	}

	public static Complex valueOf(double re, double im) {
		return new Complex(re, im);
	}
}

第18条 复合优先于继承

• 在包的内部实现继承是十分安全的，在那里子类和超类的实现都处在同一个程序员控制之下。
• 与方法调用不同的是，继承打破了封装性。换句话说，子类依赖于其超类中特定功能的实现细节。超类的实现有可能会随着发行版本的不同而有所变化，如果真的发生了变化，子类可能会遭到破坏。它们的超类在后续的发行版本中可以获得新的方法。
• 有一种方法可以避免前面的问题：不扩展现有的类，而是在新的类中增加一个私有域，它引用现有类的一个实例。这种设计被称为“复合”。（Decorator 修饰者模式）
• 包装类几乎没有什么缺点，需要注意的一点是，包装类不适合用于回调框架：在回调框架中，对象把自身的引用传递给其他的对象，用于后续的调用（“回调”）
• 只有当子类真正是超类的子类型时，才适合用继承。换句话说，对于两个类A和B，只有当两者之间确实存在“is-a”关系的时候，类B才应该扩展类A。
• 继承机制会把超类API中的所有缺陷传播到子类中，而复合则允许设计新的API来隐藏这些缺陷。
• 简而言之，继承的功能非常强大，但是也存在诸多问题，因为它违背了封装原则。

第19条 要么设计继承并提供文档说明，要么禁止继承

• 对于专门为了继承而设计并且具有良好文档说明的类来说：这个类会有一些实质性的限制。
  • 首先，该类的文档必须精确地覆盖每个方法所带来的影响。换句话说，该类必须有文档说明它可覆盖的方法的自用性。
  • 类必须以精心挑选的受保护的方法的形式，提供适当的钩子（hook），以便进入其内部工作中。
  • 对于为了继承而设计的类，唯一的测试方法就是编写子类。经验表明，3个子类通常就足以测试一个可扩展类。
  • 为了继承而设计并有可能被广泛使用的类时，必须意识到，对于文档中声明的自用模式，你实际上已经做出了永久的承诺。因此必须在发布类之前编写子类对类进行测试。
  • 构造器决不能调用可被覆盖的方法，无论是直接调用还是间接调用。（超类的构造器在子类的构造器之前运行，如果子类覆盖方法，将会在子类构造器运行之前先被调用）
  • 无论是clone还是readObject，都不可以调用可覆盖的方法，不管是以直接还是间接的方式。
  • 若你决定在一个为了继承而设计的类中实现Serializable接口，并且该类有一个readResolve或者writeReplace方法，就必须使readResolve或者writeReplace成为受保护的方法，而不是私有的方法。
• 好的API文档应该描述一个给定的方法，做了什么工作，而不是描述它是如何做到的。
• 对于那些并非为了安全进行子类化而设计和编写文档的类，要禁止子类化：一种方法是声明类为final的；另一种方法是把所有的构造器都变成私有的，或者包级私有的，并增加一些公有的静态工厂来替代构造器。
• 完全消除这个类中可覆盖方法的自用特性，就可以创建“能够安全地进行子类化”的类。
• 简而言之，专门为了继承而设计类是一件很辛苦的工作。除非知道真正需要子类，否则最好通过将类声明为final，或者确保没有可访问的构造器来禁止类被继承。

第20条 接口优于抽象类

• 接口、抽象类都可以用来定义允许多个实现的类型。区别在于抽象类，类必须成为抽象类的一个子类。
• 现有的类可以很容易被更新，以实现新的接口。
• 接口是定义mixin（混合类型）的理想选择。
• 接口允许构造非层次结构的类型框架。
• 通过第18条的包装类模式，接口使得安全地增强类的功能成为可能。
• 通过对接口提供一个抽象的骨架实现类，可以把接口和抽象类的优点结合起来。接口负责定义类型，或者还提供一些缺省方法，而骨架实现类则负责实现除基本类型接口方法之外，剩下的非基本类型接口方法。扩展骨架实现占了实现接口之外的大部分工作。这就是模板方法模式。
• 骨架实现类的美妙之处在于，他们为抽象类提供了实现上的帮助，但又不强加“抽象类被用作类型定义时”所持有的严格限制。
• 骨架实现类的编写：确定哪些方法是最为基本的，其他的方法则可以根据它们来实现。这些基本方法将成为骨架实现类中的抽象方法；在接口中未所有可以在基本方法之上直接实现的方法提供缺省方法，但要记住，不能为Object方法提供缺省方法。
• 骨架实现类是为了继承的目的而设计的，对于骨架实现类而言，好的文档绝对是非常必要的。
• 总而言之，接口通常是定义允许多个实现的类型的最佳途径。如果你导出了一个重要的接口，就应该坚决考虑同时提供骨架实现类。而且，还应该尽可能地通过缺省方法在接口中提供骨架实现，以便接口的所有实现类都能使用。

第21条 为后代设计接口

• 尽管缺省方法现在已经是Java平台的组成部分，但谨慎设计接口仍然是至关重要的。
• 在发布程序之前，测试每一个新的接口就显得尤其重要。程序员应该以不同的方法实现每一个接口，最起码不应少于三种实现。

第22条 接口只用于定义类型

• 类实现接口，接口就充当可以应用这个类的实例的类型。为了任何其他目的而定义接口是不恰当的。
• 有一种接口被称为常量接口，不满足上述条件。
• 常量接口模式是对接口的不良使用。
• 常量的几种方案：
  • 与某个类或接口紧密相关，就应该把常量添加到类或接口中，如Integer.MAX_VALUE与MIN_VALUE
  • 如果常量最好被看做枚举类型的成员，就应该用枚举类型
  • 不可实例化的工具类：如果大量利用工具类导出的常量，可以通过利用静态导入机制，避免用类名来修饰常量名。

第23条 类层次优于标签类

• 标签类：例如一个类根据某个字段决定表示一个圆还是一个矩形。
• 标签类过于冗长，容易出错，并且效率低下。
• 子类型化：能表示多种风格对象的单个数据类型。

第24条 静态成员类优于非静态成员类

• 嵌套类是指定义在另一个类内部的类。
• 嵌套类有四种：静态成员类，非静态成员类，匿名类，局部类。除了第一种外，其他三种都称为内部类。
• 静态成员类是外围类的一个静态成员，可以访问外围类的所有成员，包括那些声明为私有的成员。静态成员类是外围类的一个静态成员，与其他的静态成员一样，也遵守同样的可访问性规则。
• 静态成员类的一种常见用法是作为公有的辅助类，只有与外部类一起使用才有意义。
• 语法上，静态成员类与非静态成员类只差一个static。
• 非静态成员的每个实例都隐含地与外围类的一个外围实例相关联。
• 如果声明成员类不要求访问外围实例，就要始终把修饰符static放在它的声明中，使它成为静态成员类。
• 私有静态成员类的一种常见用法是代表外围类所代表对象的组件。
• 匿名类是在使用时同时被声明和实例化。匿名类必须保持简短（大约10行或更少）。否则会影响程序的可读性。
• 在Java中增加lambda之前，匿名类是动态地创建小型函数对象和过程对象的最佳方式。
• 局部类很少使用，在任何“可以声明局部变量”的地方，都可以声明局部类。必须非常简短。局部类有名字。
• 总而言之，如果一个嵌套类需要在单个方法之外仍然可见，就应该使用成员类；如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的；否则，就做成静态的。假设这个嵌套类属于一个方法内部，如果你只需要在一个地方创建实例，并且已经有一个预置的类型可以说明这个类的特征，就把它做成匿名类，否则，就做成局部类。

第25条 限制源文件为单个顶级类

• 一个文件中只定义一个顶级类
• 永远不要把多个顶级类或者接口放在一个源文件中

第五章 泛型

第26条 请不要使用原生态类型

• 原生态类型指的是没有类型参数的泛型，例如List是原生态类型，List不是。
• 如果使用原生态类型，就失掉了泛型在安全性和描述性方面的所有优势。
• 不能将任何元素放到Collection<?>中。
• 使用原生态类型的几个例外：
  • 必须在类文字中使用源生态类型，即List.class, String[].class合法，但是List<String.class>和List<?>.class不合法。
  • instanceof 操作符：
• 总而言之：Set