effective java 总结 effective java 英文

导语

《Effective Java》是和《Thinking in java》齐名的java进阶书籍。作者参与了JDK标准库的编写工作，对于此书的学习，让我收获很多。好记性不如烂笔头，我决定好好总结一下。本书主要内容有11章，分别从各个方面阐述了作者对于java代码编写的体会。我看的是第二版，目前最新版已经是第三版了，但是还没有在国内翻译出版。这就是英语不好的局限之处~

创建和销毁对象

1. 作者认为，使用构造方法构造对象是不优雅的。我们应该是用工厂方法来构建对象。一来可以用语义化的静态方法名来避免构造方法重载造成的迷惑性，二来可以在构造对象时进行如懒加载，校验等相关控制，因为构造方法调用后一定会返回一个新的分配了堆内存的对象引用。通常的方法名为：valueOf,of,getInstance,newInstance,getType,newType等。
2. 作者认为，对象参数过多时，为了避免冗长的setter方法调用，应该使用Builder设计模式。同时builder对象可以作为参数传递给相关方法。此处可以配合Lombok。
3. 作者认为构造单例的最好方式是枚举，同时应该注意对象序列化对单例造成的破坏。
4. 作者认为只包含静态方法和静态域的类应该私有构造器，因而不可实例化，不能被继承（子类实例化时会调用父类构造器）。个人认为也可以使用abstarct关键字。
6. 作者认为避免创建不必要的对象，如 String s =new String("hello"),这里其实就重复定义了字符串，造成了内存浪费和GC压力。还有就是循环语句中的某些对象可以在语句外面创建，在整个循环中重用。避免自动装箱造成的频繁创建对象。



8. 在我们自己管理内存时，要注意消除过期对象的引用，让JVM及时回收内存。我们自己管理内存的典型场景为我们在全局范围内持有一个数组，我们自己管理自己的数组内存，进行数据的增删改。我们要及时的将不用的对象引用从数组中通过置为null去掉。让GC内存回收内存。



9. 避免使用finalize方法。在此方法历写业务的最大问题时，该方法的调用时间是不一定的。因为GC线程的优先级很低，所以该方法的调用时机是不可控的，且性能开销很大。只建议在某些特定情况下作为安全网方法，即最后一道捕捉漏网之鱼的方法。
10. 应该重写equals方法。此处可以配合Lombok。
11. 应该同时重写hasCode方法。此处可以配合Lombok。
12. 应该要覆盖toString方法。便于调试。此处可以配合Lombok。
13. 应该谨慎的使用clone方法。因为存在浅克隆问题。
14. 对于值对象类，应该合理的实现Comparable方法。此处可以配合guava的Ordering。
15. 应该使类的成员可见性在可能的情况下最小。因为一旦类的成员暴露，那就成为创建者和调用者之间的约定。那么类的创建者就要对这些暴露的成员的稳定性负责，不能随意修改约定。
16. 应该通过方法访问域而不是直接访问域。因为可以在方法中进行相关控制。
17. 应该使对象的可变性最小。即，除非必要，所有的域都应该用final修饰，所有域都应该是私有的，所有类都不能被拓展。被拓展的类可能会被破坏封装性，即，拓展的过程中，需要去了解被拓展的类的内部实现，而不仅仅是被拓展的类暴露出来的API。
18. 复合优于继承。如上所述，继承破坏了封装性，同时复合更稳定，不会受到被复合的类的结构的改变的影响。通过复合和转发（适配器模式）可以方便的实现继承的效果。同时可以通过asType方法暴露一个被复合的类的视图模拟多态。
19. 继承是一种约定。要么提供丰富和负责任的文档告知方法的自用性，并测试被继承后的风险，要么就通过final禁止被继承。
20. 接口优于抽象类。因为单继承的局限性，同时接口之间并不一定和类一样是分层关系。通过mixin接口（如Comparable接口），可以构建功能丰富的类，并且可以灵活的实现多态。为了便捷的实现接口，可以提供一个接口默认实现骨架类（Wapper）。
21. 接口只用于定义类型，便于实现多态。不应该用来定义常量，常量属于不同的实现类的内部实现，不应该放在接口中作为API约定。
23. 通过在类中添加一个type字段来区分不同类型是不够OOP的，应该通过类的继承来实现层次。将相同的部分抽象成父类，type字段的每一个值都作为一个拓展子类。添加自己的字段和方法。



24. 用函数对象表示策略，java8之前不支持函数式编程的迂回。
25. 优先考虑静态内部类。静态内部类时访问权限的最小域。如果一个类只在本类中使用，就可以定义为私有的静态内部类。当然，它实现的接口可以有公开的访问权限。
26. 不要使用原生类型（raw type）。对于泛型类，都应该使用参数化类型。
27. 使用SupressWarn()压制编译器警告。前提是必须要了解警告的内容，同时将压制的区域最小化，避免出现诡异的问题。
28. 列表优于数组。两个原因，数组是协变的，容易产生类型转换异常。数组不支持泛型。
29. 使用泛型。避免类型转换异常。
30. 使用泛型方法。便捷的类型推导可以使代码更简洁。
31. 使用有限制的类型通配符来提高API的灵活性。
32. Class类是参数化类型，有很多类型相关的方法。如:cast等。注意灵活使用。
33. 常量推荐使用枚举定义。
34. 不要在业务中使用枚举的ordinal属性，应该自定义一个实例域。
35. 使用EnumSet来代替位域。
36. 使用EnumMap代替序数索引。枚举作为map的key时。
37. 枚举可以实现接口(因为枚举是一种特殊的类)。
38. 注解优于命名模式。通过命名约定来指定范围，不如在类或类成员上添加注解标记。
39. 使用Override注解来进行编译器检查。
40. 某些只在类上的标记，可以考虑标记接口。如Cloneable，Serialble。
41. 检查参数，快速失败。
43. 必要时对参数进行拷贝。如果方法调用者将引用传递给方法后，在方法外对引用指向的对象进行了修改，可能会造成诡异的不可预期的错误。



44. 谨慎设计方法签名。这部分内容太多，也很经典。建议时不时翻下这一节。方法名要合乎约定；不要过分追求方法便捷，除非某个功能太常用可以提供一个便捷方法，不然的话提供一个功能齐全的方法就好；避免过长的参数列表，如有必要，可以提供一个辅助类；注意方法正交性，即功能不要重复。参数优先使用接口，离散参数如布尔参数优先使用枚举。
45. 慎用重载。可以定义一个参数相关的方法名。
46. 慎用可变参数。不安全，代码不美观。建议是一个必要参数加一个可变参数。
47. 返回空数组或空集合，而不是null。
48. 为所有公开API编写文档。
49. 局部变量作用于最小化。
50. 尽可能的使用类库。
51. 精确计算使用大数类型。
52. 基本类型优于包装类型。
53. 尽量避免使用字符串。
54. 小心字符串连接的性能。
55. 接口优于反射机制。反射效率低，无法进行编译期检查。
56. 谨慎的进行优化。前期能跑就行，不要进行没有目的的优化。
57. 不要用异常进行分支控制。
58. 丰富异常信息。
59. 不要忽略异常。
60. 优先使用标准的异常。
61. 并发编程中，尽量使用并发工具类。
62. 序列化没啥用啊，不说了。

总结

我感觉这本书就是很厉害，尤其是带我理解了Super Type Token这个关于反射和泛型的概念。当然了，那又是一篇博客了，找时间我会娓娓道来的。这本书里关于类和方法的内容很精辟，让我理解了一些关于OOP迷惑。其实值得我多刷好几遍，但是我就匆忙的两三天刷完了。。。心态浮躁。第四章第五章找个午休再翻翻吧。

第一次正式的开始用Markdown写博客，感觉自己很极客。就是博客园的Markdown主题有点太low了。以后我就用这个来写博客啦。。。

后面的博客计划是总结下字节码，反射和泛型。还想着刷一本Zookeeper的书写一写Zookeeper的相关实践。就是心情太浮躁，做事效率太低，拖拖拉拉让我很烦恼。

加油吧。

自律者自由