《Effective Java》学习笔记

序

1. 语法+词汇+用法
2. 面向算法，面向函数，面向对象

 

 

 

• 引言

1. 78个条目
2. Java支持四种类型：接口（interface）、类（class）、数组（array）和基本类型（primitive）。
3. 方法的签名（signature）由名称、参数组成，不包括返回类型。
4. API元素（API element）：类、接口、构造器、成员以及序列化形式

 

 

• 创建和销毁对象

1. 考虑用静态工厂方法代替构造器
   1. 优势：
      • 有名称
      • 不必再每次调用的时候都创建一个新对象。
      • 可以返回原返回类型的任何子类型的对象
      • 在创建参数化类型实例的时候，使代码变得更加简洁。
   2. 缺点
      • 类如果不含公有的或受保护的构造器，就不能被子类化。
      • 与其他的静态方法实际上没有任何区别。
   3. 服务提供者框架（Service Provider Framework）：多个服务提供者实现一个服务，系统为服务提供者的客户端提供多个实现，并把他们从多个实现中解耦出来。
      • 三个重要组件：
        1. 服务接口（Service Interface）：提供者实现
        2. 提供者注册API（Provider Registration API）：系统用来注册实现，让客户端访问
        3. 服务访问API（Service Access API）：客户端用来获取服务的实例
      • 惯用名称：
        1. valueOf：类型转换
        2. of：EnmSet()
        3. getInstance
        4. newInstance：能够确保返回的每个实例都与所有其他实例不同
        5. getType
        6. newType
2. 遇到多个构造器参数时要考虑用构造器
   1. 重叠构造器（telescoping constructor）
      • 重叠构造器可行，但是当有很多参数的时候，客户端代码会很难编写，并且较难阅读。
   2. JavaBeans模式
      • 调用一个无参构造器来创建对象，然后调用setter方法来设置每个参数
      • 构造过程被分到几个调用中，在构造过程中JavaBean可能处于不一致的状态。
      • JavaBeans模式组织了把类做成不可变的可能。
      • 编译期无法确保程序员会在使用之前先在对象上调用freeze方法。
   3. Builder模式
      • 如果类的构造器或者静态工厂中具有多个参数，使用Builder模式。
      • 模拟了具名的可选参数
      • 在对象域而不是builder域对参数进行检验
      • Class.newInstance破坏了编译时的异常检查。
      • 不足：为了创建对象，必须先创建它的构造器。
3. 用私有构造器或枚举类型强化Singleton属性
   1. 使类成为Singleton会使它的客户端测试变得十分困难。
   2. 实现Singleton的三种方法：

享有特权的客户端可以借助AccessibleObject.setAccessible，通过反射机制调用私有构造器。

单元素的枚举类型是实现Singleton的最佳方法。

1. 通过私有构造器强化不可实例化的能力
   1. 企图通过将类做成抽象类来强制该类不可被实例化是行不通的。

使得一个类不能被子类化。所有的构造器必须显式或隐式调用超类的构造器。

1. 避免创建不必要的对象
   1. 如果对象是immutable，就始终可以被重用。
   2. 对于同时提供了静态工厂方法和构造器的不可变类，通常使用静态工厂方法，避免创建不必要的对象。Boolean.valueOf(String)
   4. 延迟初始化（lazily initializing）
   5. 适配器（adapter）：把功能委托给一个后备对象（backing object），从而为后备对象提供一个可以替代的接口。
   6. autoboxing：允许程序员将primitive和boxed primitive type混用，按需自动装箱和拆箱。
   7. 要优先使用primitive类型，当心无意识的自动装箱。
   8. 小对象的创建和回收动作是非常廉价的。
   9. 通过维护自己的对象池（object pool）来避免创建对象并不是一种好的做法，除非池中的对象是非常重量级的。
   10. 数据库连接池。
   11. defensive copying
2. 消除过期的对象引用
   1. 内存泄漏的第一个常见来源是过期引用。
      • 如果一个栈先增长，再收缩，从栈中弹出的对象不会被当做垃圾回收，即使不再引用。
      • 栈内部维护着对这些对象的过期引用（‘obsolete reference）。指永远不会再被解除的引用。
      • unintentional object retention：无意识的对象保持
      • 修复方法：一旦对象引用过期，清空引用
      • 尽快检测出程序中的错误
      • 清空对象引用应该是一种例外，而不是一种规范行为。最好的方法是让包含该引用的变量结束其生命周期。
      • 一旦数组元素变成了非活动部分的一部分，程序员就手工清空。
      • 只要类是自己管理内存，程序员就该警惕内存泄漏问题。
   2. 内存泄漏的第二个常见来源是缓存。
      • 只有当所要的缓存项的生命周期由该键的外部引用而不是由值决定时，WeakHashMap才有用处。
   3. 内存泄漏的第三个常见来源是监听器和其他回调。
      • 确保回调立即被当做垃圾回收的最佳方法是只保存他们的weak reference
3. 避免使用终结方法
   1. finalizer通常是不可预测的，也是很危险的。一般情况下是不必要的。
   2. 不要把finalizer当做C++中destructors的对应物。
   3. finailizer不能保证及时执行。注重time-critical的任务不应该由finalizer完成。
   4. finalizer线程的优先级比较低。Java语言规范并不保证哪个线程会执行finalizer。
   5. 不应该依赖finalizer更新重要的持久状态。
   6. 如果未被捕获的异常在终结过程中被抛出，可以忽略，并且该对象的终结过程也会终止。如果异常发生在终止方法中，不会打印出Stack Trace，连警告也不会打印出来。
   7. 使用终结方法有一个Severe的性能损失。
   8. 提供一个显式的终止方法。并要求该类的客户端在每个实例不再有用的时候调用这个方法。在一个私有域中记录是否已经被终止。
   9. 显式的finalizer通常与try-finally结合使用，以确保及时终止。
   10. 终结方法的合法用途
       • 当对象的所有者忘记调用显式终止方法时，finalizer可以充当safety net。
       • native peer。本地对等体是一个native object，普通对象通过native method委托给一个本地对象。
   11. finalizer chaining并不会自动执行。
   13. 为每个将被终结的对象创建一个附加的对象。把终结方法放在一个匿名类中，终结它的enclosing instance。该匿名类的单个实例被称为finalizer guardian。

 

• 1.  
• 对于所有对象都通用的方法

第八条：覆盖equals时请遵守通用规定

1. 如果不覆盖equals方法，类的每个实例都只与它自身相等。
   1. 类的每个实例本质上都是唯一的。
   2. 不关心类是否提供了“逻辑相等（logically equality）”的测试功能。
   3. 超类已经覆盖了equals，从超类继承过来的行为对于子类也是合适的。
   4. 类是私有的或是package，可以确定它的equals方法永远不会被调用。

1. value class。逻辑相等。
2. equals的通用规定
   1. equals方法实现了equivalence relation:
      • reflexivity：对于任何非null的引用值x，x.equals(x)必须返回true。对象必须等于其自身。
      • symmetric：对于任何非null的引用值x和y，当且仅当x.equals(y)返回true时，y.equals(x)返回true。任何两个对象对于“它们是否相等”的问题必须保持一致。
      • transitivity传递性：对于任何非null的引用值x/y/z，如果x.equals(y)返回true，y.equals(z)返回true，那么x.equals(z)返回true
      • consistent一致性：对于任何非null的引用值x和y，只要equals的比较操作在对象中所用的信息没有被修改，多次调用x.equals(y)会一致返回相同的结果。如果两个对象相等，它们就必须始终保持相等。
      • Non-nullity。对于任何非null的引用值x，x.equals(null)返回false
3. 一旦违反了equals规定，当其他对象面对你的对象时，这些对象的行为将无法预测。
4. Liskov substitution principle：一个类型的任何重要属性也将适用于它的子类型。因此为该类编写的任何方法，在其子类型上应同样运行的很好。
5. getClass()             instanceof
6. 复合优先于继承。
7. 不要使equals方法依赖于不可靠的资源。
8. 除了极少数例外，equals方法应该对内存中的对象执行确定性计算。
9. 为了测试参数的等同性，equals方法必须先把参数转换成适当的类型，以便调用accessor，或者访问它的域。在进行转换之前，equals方法必须使用instanceof，检查其参数是否为正确的类型。
10. 实现高质量equals方法的诀窍：
    1. 使用==检查“参数是否为这个对象的引用”。
    2. 使用instanceof 检查“参数是否为正确的类型”
    3. 把参数转换成正确的类型。
    4. 对于该类中的每个significant域，检查参数中的域是否与该对象中对应的域相匹配。
       • 既不是float也不是double的基本类型域，使用==；对象引用域，递归调用equals方法；对于float域，使用Float.compare；对于double，使用Double.compare。对于数组域，每个元素。Arrays.equals()。
       • canonical form
       • 域的比较顺序可能影响equals方法的性能。
    5. 编写完equals方法后，检测：是否对称、是否传递、是否一致。
11.  
13. 可以在一个abstract类的子类中增加新的值组件。
14. 告诫
    1. 覆盖equals时总要覆盖hashCode()
    2. 不要企图让equals方法过于智能
    3. 不要将equals声明中的Object对象替换为其他的类型。overload。

 

第九条：覆盖equals时总要覆盖hashCode

1. 约定内容
   1. Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCodemethod must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
   2. If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
   3. It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.
2. 简单的解决方法
   1. 把某个非零的常数值，保存在一个名为result的int类型变量中。
   2. 对于对象中每个关键域f（指equals方法中涉及的每个域）：
      • 为该域计算int类型的散列码c
        1. 如果该域是boolean类型，则计算(f?1:0)
        2. byte、char、short或int类型，计算(int)f
        3. long类型，计算(int)(f^(f>>>32))
        4. float类型，计算Float.floatToIntBits(f)
        5. double类型，计算Double.doubleToLongBits(f)，为得到的long类型值计算散列值
        6. 如果该域是一个对象引用，并且该类的equals方法通过递归的调用equals的方式比较这个域，则同样为这个域递归的调用hashCode。
        7. 如果该域是一个数组，则把每一个元素当做单独的域来处理。
      • 把散列码c合并到result中：
        1. result = 31 * result + c
   3. 返回result
   4. 单元测试验证
3. 在散列码的计算过程中，可以把redundant field排除在外。
4. 不要试图从散列码计算中排除掉一个对象的关键部分来提高性能。

 

 

第十条：始终要覆盖toString

1. 提供好的toString实现可以使类用起来更加舒适。
2. 在实际应用中，toString应该返回对象中包含的所有值得关注的信息。
3. 理想情况下，字符串应该是self-explanatory
4. 无论是否指定格式，都应该在文档中明确表明意图。
5. 无论是否指定格式，都为toString返回值中包含的所有信息，提供一种编程式的访问途径。

 

 

第十一条：谨慎的覆盖clone

1. Cloneable接口的目的是作为对象的一个mixin接口，表明这样的对象允许clone。
2. Cloneable接口缺少一个clone方法，Object的clone方法是受保护的。
3. 对于Cloneable接口，它改变了超类中受保护的方法的行为。
4. extralinguistic机制：无需调用构造器就可以创建对象
5. java.lang.Object的约定内容：
   1. x.clone() != x            true
   2. x.clone().getClass() == x.getClass()         true
   3. x.clone().equals(x)           true。不是绝对的要求
6. 拷贝对象往往会导致创建类的一个新实例，同时要求拷贝内部的数据结构。这个过程中没有调用构造器。
7. 如果覆盖了非final类中的clone方法，则应该返回一个通过调用super.clone()得到的对象。
8. 对于实现了Cloneable的类，总是期望提供一个功能适当的公有的clone方法。
10. covariant return type。覆盖方法的返回类型可以使被覆盖方法返回类型的子类。
11. 永远不要让客户去做任何类库能够替客户完成的事情
12. 实际上，clone方法就是另一个构造器；必须确保不会伤害到原始的对象，并确保正确的创建被克隆对象中的invariant。
13. clone架构与引用可变对象的final域的正常用法是不相兼容的。
14. 克隆复杂对象的方法：
    1. iteration
    2. recursion
    3. 先调用super.clone()，然后把结果对象中的所有域都设置成virgin state，然后调用higher-level的方法来重新产生对象的状态。
15. 如同构造器一样，clone方法不应该在构造过程中，调用新对象中任何非final的方法。
16. 所有实现了Cloneable接口的类都应该用一个公有的方法覆盖clone。
17. 另一个实现对象拷贝的好方法是提供一个copy constructor或copy factory。
18. conversion constructor

 

 

第十二条：考虑实现Comparable接口

1. 类实现了Comparable接口，就表明它的实例具有内在的natural ordering。
2. Java平台类库中的所有value classes都实现了Comparable接口。
4. compareTo方法的通用规定：
   1. 该对象小于指定对象， 返回负整数
   2. 等于， 0
   3. 大于， 返回正整数
   4. 无法比较， 抛出ClassCastException
5. 说明
   1. 必须确保所有的x和y都满足sgn(x.compareTo(y)) == -sgn(y.compareTo(x))
   2. 确保比较关系可传递：(x.compareTo(y) > 0 && y.compareTo(z) > 0)暗示着x.compareTo(z) > 0。
   3. 强烈建议(x.compareTo(y) == 0) == x.equals(y)，但并非绝对必要。
6. 与equals不同的是，compartTo可以对不同类不作比较，可以抛出ClassCastException。
7. 在通常情况下，应该返回与equals方法同样的结果。
8. 编写compareTo方法与编写equals方法的差别
   1. Comparable接口是参数化的，comparable方法是静态的类型，因此不必进行类型检查，也不必对其参数进行类型转换。
   2. compareTo方法中的域比较是顺序的比较，而不是同等性的比较。
   4. 如果一个类有多个关键域，从最关键的域开始，逐步进行到所有的重要域。
   5. compareTo方法没有指定返回值的大小，只是指定了返回值的符号。

 

1.  

• 类和接口

第十三条：使类和成员的可访问性最小化

1. 设计良好的模块会隐藏所有的实现细节，把它的API和它的实现清晰的隔离开来。
   1. 可以有效接触各模块之间的耦合关系。
   2. 提高了软件的可重用性
   3. 信息隐藏降低了构建大型系统的风险。
2. information hiding。encapsulation
3. access control
4. 尽可能的使每个类或成员不被外界访问。尽可能最小的访问级别。
5. 顶层的雷和接口，只有两种可能的访问级别：package、public
6. accessibility
   1. private
   2. package：default
   3. protected
   4. public
7. 私有成员和包级私有成员都是一个类的实现中的一部分，一般不会影响它的导出的API
8. Serializable
9. protected成员应该尽量少用。
10. 如果覆盖了超类中的一个方法，子类中的访问级别就不允许低于超类中的访问级别。
11. 接口中的所有方法都隐含着公有访问级别。
12. 实例域决不能是公有的。
13. 包含公有可变域的类并不是线程安全的。
14. 如果final域包含可变对象的引用，它便具有非final域的所有缺点。
15. 长度非零的数组总是可变的。所以，类具有公有的静态final数组域，或者返回这种域的访问方法，几乎总是错误的。
17. 修正方法：

 

 

第十四条：在公有类中使用访问方法而非公有域

1. 如果类可以在包外部进行访问，就提供访问方法。
2. 如果类是private的，或是私有的嵌套类，直接暴露它的数据域并没有本质的错误。
3. 公有类不应该直接暴露数据域
5. 公有类永远不应该暴露可变的域。

 

 

第十五条：使可变性最小化

1. 不可变类只是其实例不能被修改的类。
2. Java平台类库中包含许多不可变的类：String、boxed primitive type、BigInteger、BigDecimal
3. 为了使类成为不可变，要遵循以下五条规则：
   1. 不要提供任何会修改对象状态的方法（mutator）
   2. 保证类不会被扩展。一般做法是使该类称为final的。
   3. 使所有的域都是final的。
   4. 使所有的域都成为private的。
   5. 确保对于任何可变组件的互斥访问。defensive copy。
4. functional做法。对操作数进行运算但并不修改它。procedural、imperative。
5. 不可变对象比较简单。
6. 不可变对象本质上是线程安全的，不要求同步。
7. 不可变对象可以被自由的共享。永远也不需要进行defensive copy。不应该为不可变的类提供clone方法或copy constructor。
8. public static final
9. 不仅可以共享不可变对象，甚至可以共享它们的内部信息。
10. 不可变对象为其他对象提供了大量的building blocks。
11. 不可变类唯一的缺点：对于每个不同的值都需要一个单独的对象。
12. 公有的可变配套类。String类，其可变配套类是StringBuilder。
13. 为了确保不可变性，类绝对不允许自身被子类化。
    1. 使类成为final的
    2. 让类的所有构造器都变成private或package，并添加公有的static factory来代替公有的构造器。
14. 保护性copy
15. 没有一个方法能够对对象的状态产生externally visible的改变。
16. lazily initialization
17. 坚决不要为每个get方法编写一个相应的set方法。除非有很好的理由要让类成为可变的类，否则就应该是不可变的。
18. 不可变类的唯一缺点是在特定的情况下存在潜在的性能问题。
19. 如果类不能被做成是不可变的，应该尽可能的限制它的可变性。
20. 除非有令人信服的理由要使域编程非final的，否则要使每个域都是final的。
21. 构造器应该创建完全初始化的对象，并建立起所有的约束关系。

 

 

第十六条：复合优先于继承

1. implementation inheritance
2. 与方法调用不同的是，继承打破了封装性。
3. 子类必须要跟着超类的更新而演变。
4. self-use
5. composition
6. forwarding
7. wrapper class
8. 包装类不适合用在callback framework中。
9. SELF问题
10. 只有子类是超类的subtype时，才适合继承。
11. 继承机制会把超类API中的所有缺陷传播到子类中，而复合则允许设计新的API来隐藏这些缺陷。
12. 可以用复合和转发机制来代替继承。

 

 

 

 

 

第十七条：要么为继承而设计，并提供文档说明，要么禁止继承

1.  该类必须有文档可以说明它overridable方法的self-use。
2.  好的API文档应该描述一个给定的方法做了什么工作，而不是描述它如何做到的。
3. 类必须通过某种形式提供适当的hook，以便能够进入它的内部工作流程中。
4. 对于为了继承而设计的类，唯一的测试方法是编写子类。
5. 必须在发布类之前先编写子类对类进行测试。
6. 构造器决不能调用可被覆盖的方法。
7. Cloneable、Serializable
8. 为了继承而设计类，对这个类会有一些实质性的限制。
9. skeletal implementation
10. 对于那些并非为了安全进行子类化而设计和编写文档的类，要禁止子类化。
11. 禁止子类化的方法
    1. final
    2. 把所有的constructor都变成私有的，或者包级私有的。并增加一些公有的静态工厂来代替构造器。
12. wrapper class
13. 确保这个类永远不会调用它的任何可覆盖的方法，并在文档中说明这一点。

 

 

第十八条：接口优于抽象类

1. Java只允许单继承
2. 抽象类作为类型定义
   1. 现有的类可以很容易被更新，以实现新的接口。
   2. 接口是定义mixin（混合类型）的理想选择。
   3. 接口允许我们构造非层次结构的类型框架。
3. combinatorial explosion
4. wrapper class。接口使得安全的增强类的功能成为可能。
5. 通过对导出的每个重要接口都提供一个抽象的skeletal implementation，把接口和抽象类的优点结合起来。
6. AbstractInterface。
7. AbstractCollection、AbstractSet、AbstractList、AbstractMap。SkeletalCollection。
8. simulated multiple inheritance
10. skeletal implementation是为了继承而设计的，应遵从17条中所有关于设计和文档的指导原则。
11. simple implementation。
12. 抽象类的演变比接口的演变要容易的多。
13. 接口一旦被公开发行，并且已被广泛实现，改变这个接口几乎是不可能的。

 

 

第十九条：接口只用于定义类型

1. constant interface。不包含任何方法，只包含静态的final域。
2. 常量接口是对接口的不良使用。
3. 导出常量的合理选择方案：
   1. 如果常量与某个现有的类或接口紧密相关，就应该把这些常量添加到这个类或接口中
   2. 如果这些常量最好被看做枚举类型的成员，用enum type来导出这些常量。
   3. 使用不可实例化的utility class
4. static import。1.5。
5. 接口应该只被用来定义类型，不应该被用来导出常量。

 

 

第二十条：类层次优于标签类

1. 标签类（tagged class）过于冗长、容易出错，并且效率低下。
2. subtyping：定义能表示多种风格对象的单个数据类型。

 

 

第二十一条：用函数对象表示策略

1. Strategy模式
2. function object。其方法执行其他对象上的操作。
4. strategy interface
7. 函数指针的主要用途就是实现strategy模式。
8. 当一个具体策略只被使用一次时，通过匿名类声明和实例化这个具体策略类。当一个具体策略被设计用来重复使用的时候，实现为私有的静态成员类，并通过公有的静态final域被导出。

 

 

第二十二条：优先考虑静态成员类

1. nested class：为enclosing class提供服务。
2. 嵌套类有四种：static member class、nonstatic member class、anonymous class、local class
3. 非静态成员类的每个实例都隐含着与enclosing class的一个enclosing instance相关联。
5. 如果声明成员类不要求访问enclosing instance，就要始终把static放在其声明中。
6. 如果省略了static，每个实例都将包含一个指向enclosing object的引用。
7. 私有静态成员类的一个常见用法是用来代表外围类所代表的对象的组件。
8. 匿名类：在使用的同时被声明和实例化。
9. 匿名类的常见用法：
   1. 动态的创建函数对象
   2. 创建process object
   3. 在静态工厂方法内部
10. 局部类。

 

1.  

• 泛型

1. Java 5中增加了generic。

 

第二十三条：不要在新代码中使用原生态类型

1. generic类或接口：声明中具有一个或多个type parameter的类或接口。
2. 泛型类和接口统称为泛型。
3. 每个泛型都定义一个raw type，即不带任何实际类型参数的泛型名称。
4. 出错之后应该尽快发现，最好是编译时发现。
6. 如果使用raw type，就失掉了泛型在安全性和表述性方面的所有优势。
7. migration compati’bility
8. 泛型有子类型化（subtyping）的规则。List是raw type List的一个子类型，而不是List