《Effective Java》总结
导语
《Effective Java》是和《Thinking in java》齐名的java进阶书籍。作者参与了JDK标准库的编写工作，对于此书的学习，让我收获很多。好记性不如烂笔头，我决定好好总结一下。本书主要内容有11章，分别从各个方面阐述了作者对于java代码编写的体会。我看的是第二版，目前最新版已经是第三版了，但是还没有在国内翻译出版。这就是英语不好的局限之处~
创建和销毁对象
-
作者认为，使用构造方法构造对象是不优雅的。我们应该是用工厂方法来构建对象。一来可以用语义化的静态方法名来避免构造方法重载造成的迷惑性，二来可以在构造对象时进行如懒加载，校验等相关控制，因为构造方法调用后一定会返回一个新的分配了堆内存的对象引用。通常的方法名为：
valueOf,of,getInstance,newInstance,getType,newType等。 -
作者认为，对象参数过多时，为了避免冗长的setter方法调用，应该使用Builder设计模式。同时builder对象可以作为参数传递给相关方法。此处可以配合Lombok。
-
作者认为构造单例的最好方式是枚举，同时应该注意对象序列化对单例造成的破坏。
-
作者认为只包含静态方法和静态域的类应该私有构造器，因而不可实例化，不能被继承（子类实例化时会调用父类构造器）。个人认为也可以使用abstarct关键字。
-
作者认为避免创建不必要的对象，如
String s =new String("hello"),这里其实就重复定义了字符串，造成了内存浪费和GC压力。还有就是循环语句中的某些对象可以在语句外面创建，在整个循环中重用。避免自动装箱造成的频繁创建对象。
-
在我们自己管理内存时，要注意消除过期对象的引用，让JVM及时回收内存。我们自己管理内存的典型场景为我们在全局范围内持有一个数组，我们自己管理自己的数组内存，进行数据的增删改。我们要及时的将不用的对象引用从数组中通过置为
null去掉。让GC内存回收内存。
-
避免使用finalize方法。在此方法历写业务的最大问题时，该方法的调用时间是不一定的。因为GC线程的优先级很低，所以该方法的调用时机是不可控的，且性能开销很大。只建议在某些特定情况下作为安全网方法，即最后一道捕捉漏网之鱼的方法。
-
应该重写equals方法。此处可以配合Lombok。
-
应该同时重写hasCode方法。此处可以配合Lombok。
-
应该要覆盖toString方法。便于调试。此处可以配合Lombok。
-
应该谨慎的使用clone方法。因为存在浅克隆问题。
-
对于值对象类，应该合理的实现
Comparable方法。此处可以配合guava的Ordering。 -
应该使类的成员可见性在可能的情况下最小。因为一旦类的成员暴露，那就成为创建者和调用者之间的约定。那么类的创建者就要对这些暴露的成员的稳定性负责，不能随意修改约定。
-
应该通过方法访问域而不是直接访问域。因为可以在方法中进行相关控制。
-
应该使对象的可变性最小。即，除非必要，所有的域都应该用
final修饰，所有域都应该是私有的，所有类都不能被拓展。被拓展的类可能会被破坏封装性，即，拓展的过程中，需要去了解被拓展的类的内部实现，而不仅仅是被拓展的类暴露出来的API。 -
复合优于继承。如上所述，继承破坏了封装性，同时复合更稳定，不会受到被复合的类的结构的改变的影响。通过复合和转发（适配器模式）可以方便的实现继承的效果。同时可以通过
asType方法暴露一个被复合的类的视图模拟多态。 -
继承是一种约定。要么提供丰富和负责任的文档告知方法的自用性，并测试被继承后的风险，要么就通过final禁止被继承。
-
接口优于抽象类。因为单继承的局限性，同时接口之间并不一定和类一样是分层关系。通过mixin接口（如
Comparable接口），可以构建功能丰富的类，并且可以灵活的实现多态。为了便捷的实现接口，可以提供一个接口默认实现骨架类（Wapper）。 -
接口只用于定义类型，便于实现多态。不应该用来定义常量，常量属于不同的实现类的内部实现，不应该放在接口中作为API约定。
-
通过在类中添加一个type字段来区分不同类型是不够OOP的，应该通过类的继承来实现层次。将相同的部分抽象成父类，type字段的每一个值都作为一个拓展子类。添加自己的字段和方法。
-
用函数对象表示策略，java8之前不支持函数式编程的迂回。
-
优先考虑静态内部类。静态内部类时访问权限的最小域。如果一个类只在本类中使用，就可以定义为私有的静态内部类。当然，它实现的接口可以有公开的访问权限。
-
不要使用原生类型（raw type）。对于泛型类，都应该使用参数化类型。
-
使用
SupressWarn()压制编译器警告。前提是必须要了解警告的内容，同时将压制的区域最小化，避免出现诡异的问题。 -
列表优于数组。两个原因，数组是协变的，容易产生类型转换异常。数组不支持泛型。
-
使用泛型。避免类型转换异常。
-
使用泛型方法。便捷的类型推导可以使代码更简洁。
-
使用有限制的类型通配符来提高API的灵活性。
-
Class类是参数化类型，有很多类型相关的方法。如:
cast等。注意灵活使用。 -
常量推荐使用枚举定义。
-
不要在业务中使用枚举的
ordinal属性，应该自定义一个实例域。 -
使用EnumSet来代替位域。
-
使用EnumMap代替序数索引。枚举作为map的key时。
-
枚举可以实现接口(因为枚举是一种特殊的类)。
-
注解优于命名模式。通过命名约定来指定范围，不如在类或类成员上添加注解标记。
-
使用Override注解来进行编译器检查。
-
某些只在类上的标记，可以考虑标记接口。如
Cloneable，Serialble。 -
检查参数，快速失败。
-
必要时对参数进行拷贝。如果方法调用者将引用传递给方法后，在方法外对引用指向的对象进行了修改，可能会造成诡异的不可预期的错误。
-
谨慎设计方法签名。这部分内容太多，也很经典。建议时不时翻下这一节。方法名要合乎约定；不要过分追求方法便捷，除非某个功能太常用可以提供一个便捷方法，不然的话提供一个功能齐全的方法就好；避免过长的参数列表，如有必要，可以提供一个辅助类；注意方法正交性，即功能不要重复。参数优先使用接口，离散参数如布尔参数优先使用枚举。
-
慎用重载。可以定义一个参数相关的方法名。
-
慎用可变参数。不安全，代码不美观。建议是一个必要参数加一个可变参数。
-
返回空数组或空集合，而不是null。
-
为所有公开API编写文档。
-
局部变量作用于最小化。
-
尽可能的使用类库。
-
精确计算使用大数类型。
-
基本类型优于包装类型。
-
尽量避免使用字符串。
-
小心字符串连接的性能。
-
接口优于反射机制。反射效率低，无法进行编译期检查。
-
谨慎的进行优化。前期能跑就行，不要进行没有目的的优化。
-
不要用异常进行分支控制。
-
丰富异常信息。
-
不要忽略异常。
-
优先使用标准的异常。
-
并发编程中，尽量使用并发工具类。
-
序列化没啥用啊，不说了。
总结
我感觉这本书就是很厉害，尤其是带我理解了Super Type Token这个关于反射和泛型的概念。当然了，那又是一篇博客了，找时间我会娓娓道来的。这本书里关于类和方法的内容很精辟，让我理解了一些关于OOP迷惑。其实值得我多刷好几遍，但是我就匆忙的两三天刷完了。。。心态浮躁。第四章第五章找个午休再翻翻吧。
第一次正式的开始用Markdown写博客，感觉自己很极客。就是博客园的Markdown主题有点太low了。以后我就用这个来写博客啦。。。
后面的博客计划是总结下字节码，反射和泛型。还想着刷一本Zookeeper的书写一写Zookeeper的相关实践。就是心情太浮躁，做事效率太低，拖拖拉拉让我很烦恼。
加油吧。
