Effective Java（一）

Effective Java这本书的意义在于提供最佳实践，而所谓的最佳实践又并非时时刻刻都需要这么做，所以我们需要引入问题场景。关于什么样的问题用什么的方式来解决，重要的是思考，其次是模仿。

虽然说是最佳实践，但是有时候又有些局限，局限于某个Java版本，以及某些Java的设计，还有一些今天看来已经有些过时。

这本书写于Java1.6的时代，虽然1.6是一个跨时代的版本，但是有些内容在今天来看已经有些过时了，这边文章主要在于梳理这些已经过时的东西，以及温习一下这本书所教所讲。

仅涉及了部分章节，有部分疏漏。

例如静态工厂模式提到，它可以使原本冗余的类型声明变得简洁。

Map> m = new HashMap>();

实际上，在Java7已经支持了这种类型推导，并且支持声明缺省，写成如下样子。

Map> 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垃圾回收

尽管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