effective java

1.考虑用静态工厂方法代替构造函数
  对于一个类，为了让客户获得他的一个实例，最通常的方法是提供一个共有的构造函数。
 实际上还有另外一种技术，尽管较少为人所知，但也应该成为每个程序员的工具箱中的一
 部分，类可以提供一个公有的  静态工厂方法 。所谓静态工厂方法，实际上只是一个简单
 的静态方法，他返回的是类的一个实例。
  类可以提供一些静态工厂方法，来代替构造函数，或者同时也提供好一些构造函数。用静态
 工厂来代替公有的构造函数，既有好处，也有不足之处。
 
  静态工厂方法的一个好处是，与构造函数不同，静态工厂方法具有名字，返回值等，可以通过
 名字就能知道代码的含义。
  静态工厂方法的第二个好处是，与构造函数不同，他在被调用时，并不要求非得创建一个新的对象。
  静态工厂方法的第三个好处是，与构造函数不同，他们可以返回一个原返回类型的子类型的对象。
  
  静态工厂方法的主要缺点是，类如果不含公有的或者受保护的构造函数，就不能被子类化。
  静态工厂方法的第二个缺点是，他们和其他的静态方法没有任何区别。
  

2.使用私有构造函数强化singleton属性
  singleton是指这样的类，他只能实例化一次，singleton通常被用来代表那些本质上具有唯一性的
 系统组件。
  实现singleton有两种方法：这两种方法都要把构造函数保持私有的，并且提供一个静态成员，以便
 允许客户能够访问该类的唯一实例，在第一种方法中，公有静态成员是一个final域：
     
     public class Elvis{
     
      public static final Elvis INSTANCE = new Elvis();
      
      private Elvis(){
      }
     }
  私有构造函数仅被调用一次，用来实例化公有的静态final域，由于缺少公有或者受保护的构造函数，所以保证了全局唯一性，一旦类被实例化之后，只有一个实例存在--不多也不少。
  客户的任何行为都不会改变这一点。
  
  第二种方法提供了一个公有的静态工厂方法，而不是共有的静态final域：
  
     public class Elvis{
      private static final Elvis INSTANCE = new Elvis();
      
      private Elvis(){
      }
      
      public static Elvis getInstance(){
       return INSTANCE;
      }
     }
  所有对于静态方法的调用，杜辉返回同一个对象引用，所以，不会有别的实例被创建。
   第一种方法的主要好处在于，组成类的成员的申明很清楚的表明了这个雷是一个singleton.
  公有的静态域是final的，所以该域将总是包含相同的对象引用，第一种方法可能在性能上稍微
  领先，但是在第二种方法中，一个优秀的jvm实现应该能够通过将静态工厂方法的调用内联化，来消除这种差别。
   第二种方的主要好处在于，他提供了灵活性，在不改变API的前提下，允许我们改变想法，把该类做成singleton,
  或者不做成singleton，singleton的静态工厂方法返回该类的唯一实例，但是他也容易被修改，比如说，为每一个
  调用该方法的线程返回一个唯一的实例。
   总而言之，如果你确信该类将永远是一个单例，那么使用第一种方法是有意义的，如果你希望留有余地，那么请使用
  第二种方法。
   为了使一个单例类变成可序列化，仅仅在申明中加上“ implements Serializable” 是不够的，为了维护单例性，你必须也要提供
  一个readResolve方法，否则的话，一个序列化的实例在每次反序列化的时候，都会导致创建一个新的实例。
  
  
3.通过私有构造函数强化不可实例化的能力
  企图通过将一个类做成抽象类来强化该类不能被实例化，这个是行不通的，该类可以被子类化，而子类可以被实例化。我们只要
 让这个类包含单个显示的私有构造函数，那么他就不能被实例化了。
 
 
4.避免创建重复对象

5.消除过期的对象引用

6.避免使用终结函数

7.在改写equals的时候请遵守通用约定
  一个类的每一个实例本质上都是唯一的。
  不关心一个类是否提供了逻辑相等的测试功能。
  超类已经改写了equals，从超类继承过来的行为对于子类也是合适的。
  一个类时私有的，或者是包级私有的，并且可以确定他的equals方法永远也不会被调用。尽管如此，在这样的情况下，应该要改写equals方法，以免万一有一天他会被调用
    public boolean equals(Object o){
      throw new UnsupportedOperationException();
    } 
  那么，什么时候应该改写equals呢？当一个类有他自己特有的逻辑相等概念，而且超类没有改写equals以实现期望的行为，这是我们需要改写，这通常适合于值类的情形。
  比如Integer或者Date，程序员在利用equals方法来比较两个指向值对象的引用的时候，希望知道他们逻辑上是否相等。而不是他们是否指向同一个对象。
   在改写equals方法的时候，你必须要遵守他的通用约定，下面是约定的内容，来至Object：
    （1）equals方法实现了等价关系：
    自反性。对于任意的引用至x，x.equals(x)一定为TRUE。
    对称性。对于任意的引用值x和y，当且仅当x.equals(y)返回TRUE，那么y.equals(x)也一定返回TRUE。
    传递性。对于任意的引用值x,y和z,如果x.equals(y)返回TRUE，并且y.equals(z)也返回true，那么x.equals(z)也一定返回true。      
    一致性。对于任意的引用值x和y，如果用于equals比较的对象信息没有被修改的话，那么多次调用要么一致返回TRUE，那么一致的返回FALSE。
    对于任意的非空引用值x,x.equals(null)一定返回false.
    
  下面是为实现高质量equals方法的一个处方：
  1.使用==操作符检查“实参是否为指向对象的一个引用”。如果是的话，则返回TRUE。这只不过是一种性能的优化，如果比较操作有可能非常耗时的话，这样做的值得的。
  2.使用instanceof操作符检查实参是否正确的类型。
  3.把实参转换成正确的类型。因为前面已经有了instanceof测试，所以这个转换可以确保成功。
  4.对于该类中每一个关键域，检查实参中的域与当前对象中对应的域值是否匹配
  5.当你编写完成了equals方法后，应该问自己三个问题：他是否对称的，传递的，一致的，如果答案是否定的，那么请找到这些特性未能满足的原因，在修改代码。
   当你改写equals的时候，总是要改写hashcode.
   不要试图让equals方法过于聪明。
   不要使equals方法依赖不可靠的资源。
   不要将equals申明中的Object对象替换为其他的类型。
   
   
8.改写equals时总要改写hashCode
  一个常见的错误根源在于没有改写hashcode方法，在每一个改写了equals方法的类中，你必须也要改写hashcode，如果不这样做的话，就会违反Object.hashcode的通用约定，从而导致该类无法与所有基于散列值的集合类结合在一起正常工作。
    下面是hashcode约定的内容，来至java.lang.Object的规范：
    （1）在一个应用程序执行期间，如果一个对象的equals方法比较所用到的信息没有被修改的话，那么对该对象调用hashcode方法多次，他必须始终如一的返回同一个整数。
    （2）如果两个对象根据equals（Object）方法时相等的，那么调用这两个对象中任一个对象的hashcode方法必须产生相同的整数结果。
    （3）如果两个对象根据equals方法时不相等的，那么调用这两个对象中的任一个对象的hashcode方法，不要求必须产生不同的整数结果。然而，程序员应该意识到这样的事实，对于不同的对象产生截然不同的整数结果，有可能提高散列表的性能。
 不要试图从散列码计算中排除一个对象的关键部分以提高性能。
 
 
9.总是要改写toString
 虽然不重要，但是一个好的toString实现，可以使一个类用起来更加愉快。
 在实际应用中，toString方法应该返回对象中包含的所有令人感兴趣的信息。
 不管你是否决定指定格式，都应该在文档中明确的表明你的意图。
 
 
 
10.谨慎改写clone
    为了实现cloneable接口，使它对一个类确实产生效果，它和所有的超类都必须遵守一个相当复杂的，
  不可实施的，并且基本上没有文档说明的协议，由此得到一种语言本身之外的机制：无需调用构造函数就可以
  创建一个对象。
    Clone方法的通用约定是非常弱的，下面是来至java.lang.Object规范中的约定内容：
   创建和返回该对象的一个拷贝，这里的拷贝精确的含义取决于该对象的类，一般的含义是，对于任何对象x，表达式
     x.clone() != x
   将会是TRUE，并且，表达式
     x.clone().getClass() == x.getClass()
   将会是TRUE，但是这些都不是绝对的要求，虽然，通常情况下，表达式
     x.clone().equals(x)
   将会返回TRUE，但是这也不是一个绝对要求，拷贝一个对象旺旺会导致创建该类的一个新实例，但同时他也会要求拷贝内部的数据结构。
   这个过程中没有调用构造函数。
     实际上，clone方法是另一个构造函数，你必须确保他不会伤害到原始的对象，并且正确的建立起被克隆对象中的约束关系。
   clone结构与指向可变对象的final域的正常用法是不兼容的。
   
   
11.考虑实现comparable接口
  compareTo方法的通用约定与equals方法的通用约定具有相似的特征，下面是她的内容，摘自Comparable的规范:
   将当前这个对象与制定的对象进行顺序比较，当该对象小于等于或者大于指定对象的时候，分别返回一个负数，零或者正整数。如果由于指定对象的
  类型而使得无法进行比较，则抛出ClassCastExceptions异常。
   在下面的说明中，记号sgn表示数学上的signum函数，它根据expression的值为负值，零和正值，分别返回-1，0或1.
   实现者必须保证对于所有的x和y，满足sgn(x.compareTO(y))==sgn(y.compareTo(x))
   实现者也必须保证这个比较关系是可传递的：x.compareTo(y)>0 && y.compareTo(z)>0，那么x.compareTo(z)>0;
   最后实现者保证x.compareTo(y)==0暗示着：对于所有的z,sgn(x.compareTo(z))==sgn(y.compareTo(z));
   强力建议(x.compareTo(y) ==0) == (x.equals(y))，但这不是严格要求的，一般而言，任何实现了Compareble接口的类，若违反了这个条件，应该明确的予以说明，推荐使用这样的说法，注意这个类
  具有内在的排序功能，但是与equals不一致。

12.使类和成员的可访问能力最小化
  经验表明，你应该尽可能的是每一个类或成员不被外界访问。
  具有公有的静态final数组域几乎总是错误的，
  
  
  
13.支持费可变性
  1.不要提供任何会修改对象的方法。
  2.保证没有可被子类改写的方法。
  3.使所有的域都是final的。
  4.使所有的域都称为私有的。
  5.保证对于任何可变组件的互斥访问。
  
  总而言之，坚决不要为每一个get方法编写一个对应的set方法，除非有很好的理由要让一个类称为可变类，否则就应该是非可变的。
  
  

14.复合优先于继承
  继承是实现代码重用的有利手段，但他并不总是完成这项工作的最佳工具。不适当的使用继承或导致脆弱的软件，在一个包的内部使用继承是非常安全的
 然而，对普通的具体类进行跨越包边界的继承，则是非常危险的。
 
  与方法调用不同的是，继承破坏了封装性。
  
  
15.要么专门为继承而设计，要么禁止继承。

16.接口优先于抽象类。
  已有的类可以很容易被更新，以实现新的接口。
  接口是定义mixin(混合类型)的理想选择
  接口使得我们可以构造出非层次结构的类型框架
  接口使得安全的增强一个类的功能成为可能。
  
  使用抽象类来定义允许多个实现的类型，比使用接口有一个明显的优势：抽象类的演化比接口的演化比接口的演化要容易很多。如果在后续的发型版本中，你希望在抽象类中增加一个新的方法，
  那么，你总是可以增加一个具体方法，他包含了一个合理的默认实现，然后，，该抽象类的所有已有的实现都自动提供了这个新的方法。对于接口，这样做是行不通的。
  
  
17.接口只是被用于定义类型
  当一个类实现了一个接口的时候，这个接口被用作一个类型，通过此类型可以引用这个类的实例，因此一个类实现了一个接口，就表明客户可以对这个类的实例实施是某些动作，为了任何其他目的
  而定义接口是不合适。
  常量接口模式是对接口的不良使用。