1、考虑用静态工厂方法代替构造器

优：

① 有名称

② 不必在每次调用它们的时候都创建一个对象

③ 可以放回原返回类型的任何子类型的对象

④ 在创建参数化类型实例的时候，代码更简洁

缺：

① 类如果不含公有的或受保护的构造器，就不能被子类化

② 与其他一般的静态方法无多大区别

2、 遇到多个构造器参数时要考虑用构造器

3、用私有构造器或者枚举类型强化 Singleton 属性

4、通过私有构造器强化不可实例化的能力

5、避免创建不必要的对象

6、消除过期的对象引用

7、避免使用终结方法

 

8、覆盖 equals 时请遵守通用约定

① 类的每个实例本质上是唯一的

② 不关心类是否提供了“逻辑相等”的测试功能

③ 超类已经覆盖了 equals， 从超类继承过来的行为对于子类也是合适的

④ 类是私有的或包级私有的，可以确定它的 equals 方法永远不会被调用

 

实现高质量 equals 方法诀窍：

① 使用 “==”操作符检查“参数是否为这个对象的引用”

② 使用 instanceof 操作符检查“参数是否为正确的类型”

③ 把参数转换为正确的类型

④ 对于该类中的每个“关键”域，检查参数中的域是否参与该对象中的对应的域相匹配

⑤ 当你编写完成了 equals 方法之后，应该判断其是否满足了 对称性、传递性、一致性

9、覆盖 equals 时总要覆盖 hashCode

10、始终要覆盖 toString

11、谨慎地覆盖 clone

12、考虑实现 Comparable 接口

 

13、使类和成员的可访问性最小化

14、在公有类中使用访问方法而非公有域

15、使可变性最小化

① 不要提供任何会修改对象状态的方法

② 保证类不会被扩展

③ 使所有的域都是 final 的

④ 使所有的域都成为私有的

⑤ 确保对于任何可变组件的互斥访问

16、复合优先于继承

　　简而言之，继承的功能非常强大，但是也存在诸多问题，因为它违背了封装原则。只有当子类和超类之间确实存在子类类型关系时，使用继承才是恰当的。即便如此，如果子类和超类处在不同的包中，并且超类并不是为了继承而设计的，那么继承将会导致脆弱性。为了避免，可以用复合和转发机制来代替继承，尤其是当存在适合的接口可以实现包装类的时候。包装类不仅比子类更加健壮，而且功能也更加强大。

17、要么为继承而设计，并提供文档说明，要么就禁止继承

18、接口优于抽象类

① 现有的类可以很容易被更新，以实现新的接口

② 接口的定义的理想选择

③ 接口允许我们构造非层次结构的类型框架

　　接口通常是定义允许多个实现的类型的最佳途径。这条规律有个例外，即当演变的容易性比灵活性和功能更为重要的时候。在这种情况下，应该使用抽象类来定义类型，但前提是必须理解并且可以接受这些局限性。如果你导出了一个重要的接口，就应该坚决考虑同时提供骨架实现类。最后，应该尽可能谨慎的设计所有的公有接口，并通过编写多个实现类对它们进行全面的测试。

19、接口只用于定义类型

　　　　接口应该只被用来定义类型，它们不应该被用来导出常量。

20、类层次优于标签类

　　标签类很少有适用的时候。当你想要编写一个包含显示标签域的类时，应该考虑一下，这个标签是否可以被取消，这个类是否可以用类层次来代替。当你遇到一个包含标签域的现有类时，就要考虑将它重构到一个层次结构中去。

21、用函数对象表示策略

　　要声明一个接口来表示该策略，并且为每个具体策略声明一个实现了该接口的类。当一个具体策略只被使用一次时，通常实现匿名类来声明和实例化这个具体策略类。当一个具体策略类是设计用来重复使用的时候，它的类通常就要被实现为私有的静态成员类，并通过公有的静态 final 域被导出，其类型为该策略接口。

22、优先考虑静态成员类

　　静态成员类、非静态成员类、匿名类、局部类

① 如果一个嵌套类需要在单个方法之外仍然是可见的，或者他太长了，不适合于放在内部，就应该使用成员类。

② 如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的；否则就做成静态的。

③ 假设这个嵌套类属于一个方法的内部，如果你只需要在一个地方创建实例，并且已经有一个预置的类型可以说明这个类的特征，就要把它做成匿名类；否则，就做成局部类。

 

23、请不要在新代码中使用原生态类型

24、消除非受检警告

　　每一条警告都表示可能在运行时片抛出 ClassCastException 异常。要尽最大的努力消除这些警告。如果无法消除非受检警告，同时可以证明引起警告的代码是类型安全的，就可以在尽可能小的范围中，用 @SuppressWarnings("unchecked")注释禁止该警告。要用注释把禁止该警告的原因记录下来。

25、