Effective Java这本书的意义在于提供最佳实践，而所谓的最佳实践又并非时时刻刻都需要这么做，所以我们需要引入问题场景。关于什么样的问题用什么的方式来解决，重要的是思考，其次是模仿。
虽然说是最佳实践，但是有时候又有些局限，局限于某个Java版本，以及某些Java的设计，还有一些今天看来已经有些过时。
这本书写于Java1.6的时代，虽然1.6是一个跨时代的版本，但是有些内容在今天来看已经有些过时了，这边文章主要在于梳理这些已经过时的东西，以及温习一下这本书所教所讲。
仅涉及了部分章节，有部分疏漏。
例如静态工厂模式提到，它可以使原本冗余的类型声明变得简洁。
Map<String, List<String>> m = new HashMap<String, List<String>>();
实际上，在Java7已经支持了这种类型推导，并且支持声明缺省，写成如下样子。
Map<String, List<String>> m = new HashMap<>();
再比如构造器模式，解决的问题场景很明确，那就是一个类可能有多个多种构造参数，比较常见的做法就是空的构造函数，通过setter设置需要的参数，这就是我们说的JavaBean模式。而这种模式带来的问题是，可能存在不一致的风险，需要比较大的成本来保持一致性，不过大多数情况这种构造初始化不会很少会用于并发的场景，所以这里也不再讨论线程安全的问题。
作者借线程安全引出了Builder构造器模式，我认为这个模式的优点主要是两点：
1. 便于可选参数构造的构造
2. 便于校验&设置参数的默认值
3. 可以将生成的目标类设置为不可变对象，并且便于阅读
工具类在私有构造方法中抛出异常，来避免工具类实例化，虽然是一个技巧，然而工具类的方法均是static的，在现在的编辑器比如IDEA中，实例化一个类并调用它的静态方法，会被编辑器提示没必要的实例化，所以这个模式今天来看也不是特别必要。而且像工具类，除了系统提供的Arrays这种，大多数的命名风格是StringUtils这个样子，已经逐渐成为一种默契，我们也不会去实例化这种对象。
如何不让一个类可以被实例化：
将构造方法声明成私有方法，并throw 一个assertionError(), 当然这个throw不是必须的。
创建对象依然是有成本的，尽可能复用已有的对象，避免没有必要的装箱。
但是这又不是绝对的，再一次说明了，场景决定设计，这里对比保护性拷贝提到反驳这个观点的一个经典场景。
private final Date time;
public Date time() {
return this.time;
}
尽管time是final，保证了time的不可变，但是不能保证time的内置参数不可变，例如依然可以执行
time().setYear(233);
这样的操作会破坏time的原始值，如果这里设置保护性拷贝。
publi Date time() {
return new Date(this.time.getTime());
}
这样无论如何修改返回的Date对象，都不会影响到最原始的time对象，暴露私有变量需要考虑这样的安全性。
网上流传了一张比如Java垃圾回收的图，如下
尽管Java有GC，但是依然会有一些内存泄漏的隐患，其实关注对应的场景即可。
1. 类自己管理内存，那么可能会有内存泄漏的风险，比如Stack类弹出的元素，依然占据着引用，需要手动清理。
2. 谨慎缓存中的对象。
3. 监听器与回调。
需要补充的是，在一些场景下，大量创建对象也是内存消耗的罪魁祸首，由于不合理的创建对象导致内存疯涨，导致频繁CMS或者fullgc屡见不鲜。
覆盖equals同时要覆盖hashcode，这个很好理解，大多数集合类是依据hashcode来做对象区分的。
关于Comparable方法的实现，在如今的Java8已经不需要去实现匿名内部类了，可以直接使用方法引用或者lambda表达式来解决这样的问题。
lambda表达式：
list.sort((pre, last) -> pre.valueOf().compareTo(last.valueOf()));
引用的方式：
在对象里实现一个静态对比的方式，假设类叫MyObject，方法叫compareByNum
list.sort(MyObject::compareByNum);
在讨论可变性的问题的时候，讨论了一种编程的做法。
函数式编程functional，与之对应的还有，过程式编程（procedural），命令式编程（imperative），声明式编程（declarative）。
函数式编程通过函数调用返回新的实例，而不改变原有实例。
过程式编程or命令式编程，其实是一种东西，关注的是如何做，而不是做什么。
声明式在于，做什么，而非怎么做，比如IoC
函数式和声明式不是一个层面上的东西，函数式更关注的是处理数据的方式。
复合和接口的转发（复合模式-包装类）
这里的一个思想是说，继承与封装是矛盾的，一个类对另一个类进行了继承，那么就有可能受到他的改动产生的影响。
将现有的类作为新类的一个组件（成员变量），心累中的每个实例都可以调用被包含的现有类的方法。
通过这样转发的形式，使新类不受现有类的实现细节影响。
虽然继承非常好用，但是继承可能带来的问题是非常多的。
构造器不能去调用可被覆盖的方法，这是有极大风险的。
是否考虑使用继承，应该充分考虑可继承的方法可以自用性，方法之间相互调用，在继承的时候会存在各种各样的风险。
如何拒绝继承?
1. 把这个类声明称final类型
2. 将构造器变成私有的，使用公有的静态工厂来替代构造器。
接口在Java8引入了接口的default实现，由于接口是可以多继承的，那么一个新的问题就是多继承。Java8在处理多继承是通过显式指定继承某个父接口来决定的。
21条提到的用函数对象表示策略，使用内部静态类与静态final不可变成员实现了函数指针，在Java8中可以直接使用lambda做这个事情。
通过这样的方式可以实现策略模式，通过声明一个抽象的策略接口，为每个具体策略实现对应的接口类。
Java中有四种嵌套类定义：
1. 静态成员类 > 和普通的类没区别，主要用共有类的辅助类。
2. 非静态成员类 > 与外围类的实例关联，可以调用外围类的方法，不能独立创建。
3. 匿名类 > 匿名的Comparator实例用来给Arrays.sort()使用，一般非常短。
4. 局部类 > 基本不用，声明变量的地方即可声明局部类。
泛型的意义：
泛型不代表没有类型，显式指定泛型的声明，可以保证泛型受检。
RuntimeError
Object[] objectArray = new Long[1];
compile error
List<Object> ol = new ArrayList<Long>();
Java的泛型会在运行时进行类型擦除，泛型不是没有类型。但是Java的泛型，在编译时还存留类型信息，在运行时已经擦除了这种信息（主要为了保证使用泛型的代码和没有使用泛型的代码互用）。
枚举类型需要这样的一个场景，比如加减乘除进行枚举设计，但是他们又是不同的行为。
可以定义一个抽象的apply方法，强制每个枚举成员去覆盖实现，代码如下：
其中abstract的抽象方法，也可以使enum通过继承的方式来拓展。
