Java：Effective java学习笔记之 接口只用于定义类型、类层次优于标签类

1、 接口只用于定义类型

当类实现接口时，接口就充当可以引用这个类的实例的类型。因此，类实现了接口，就表明可以对这个类的实例实施某些动作。那么，不是为了这个目的而定义接口就是不恰当的

1.1、常量接口

有一种接口被称为常量接口，它不满足上述条件，这种接口没有包含任何方法，它只包含静态的final域，每个域都导出一个常量。

public interface PhysicalConstants {
    static final double AVOGADROS_NUMBER = 6.022141;
    static final double BOLTZMANN_CONSTANT = 1.12588456e-23;
    static final double ELECTRON_MASS = 9.10938188e-31;
}


public class test implements PhysicalConstants {
     public static void main(String[] args) {
         Double d = 11.11;
         if(d.equals(AVOGADROS_NUMBER)){
             System.out.println(d);
         }
    }
}

常量接口模式是对接口的不良使用。 类在内部使用某些常量，这纯粹是实现细节。

• 实现常量接口，会导致把这样的实现细节泄露到该类的导出API中。
• 更糟糕的是，他代表了一种承诺：如果将来的发行版本中，这个类被修改了，他不再需要使用这些常量了，他依然必须实现这个接口，以确保二进制兼容性。
• 如果非final类实现了常亮接口，他的所有子类的命名空间也会被接口中的常量所“污染”。

在java平台类库中有几个常量接口，例如java.io.ObjectStreamConstants。这些接口应该被认为是反面的典型，不值得被效仿。

package java.io;

/**
 * Constants written into the Object Serialization Stream.
 *
 * @author  unascribed
 * @since JDK 1.1
 */
public interface ObjectStreamConstants {

    /**
     * Magic number that is written to the stream header.
     */
    final static short STREAM_MAGIC = (short)0xaced;

    /**
     * Version number that is written to the stream header.
     */
    final static short STREAM_VERSION = 5;

    /* Each item in the stream is preceded by a tag
     */

    /**
     * First tag value.
     */
    final static byte TC_BASE = 0x70;

public class ObjectInputStream
    extends InputStream implements ObjectInput, ObjectStreamConstants
{
    /** handle value representing null */
    private static final int NULL_HANDLE = -1;

    /** marker for unshared objects in internal handle table */
    private static final Object unsharedMarker = new Object();

    /** table mapping primitive type names to corresponding class objects */
    private static final HashMap<String, Class<?>> primClasses
        = new HashMap<>(8, 1.0F);

(省略若干行)

    /**
     * The readStreamHeader method is provided to allow subclasses to read and
     * verify their own stream headers. It reads and verifies the magic number
     * and version number.
     *
     * @throws  IOException if there are I/O errors while reading from the
     *          underlying <code>InputStream</code>
     * @throws  StreamCorruptedException if control information in the stream
     *          is inconsistent
     */
    protected void readStreamHeader()
        throws IOException, StreamCorruptedException
    {
        short s0 = bin.readShort();
        short s1 = bin.readShort();
        if (s0 != STREAM_MAGIC || s1 != STREAM_VERSION) {
            throw new StreamCorruptedException(
                String.format("invalid stream header: %04X%04X", s0, s1));
        }
    }

如果要导出常量，可以有几种合理的选择方案。

1、如果这些常量与某个现有的类或者接口紧密相关，就应该把这些常量添加到这个类或者接口中。例如，在java平台类库中所有的数值包装类，比如Integer和Double，都导出了MIN_VALUE和MAX_VALUE常量。

public final class Integer extends Number implements Comparable<Integer> {
    /**
     * A constant holding the minimum value an <code>int</code> can
     * have, -2<sup>31</sup>.
     */
    public static final int   MIN_VALUE = 0x80000000;

    /**
     * A constant holding the maximum value an <code>int</code> can
     * have, 2<sup>31</sup>-1.
     */
    public static final int   MAX_VALUE = 0x7fffffff;

2、如果这些常量最好被看做枚举类型的成员，就应该用枚举类型（enum type）（见30条）来导出这些常量。

3、使用不可实例化的工具类（utility class）（见4条）来导出这些常量

public class PhysicalConstants {

    private PhysicalConstants(){}
    //阿伏伽德罗数
    public static final double AVOGADROS_NUMBER = 6.02214199e23;

    //玻尔兹曼常数
    public static final double BOLRZMANN_CONSTANT = 1.3806503E-23;

    //电子质量
    public static final double ELECTRON_MASS = 9.10938188E-31;
}

工具类通常要求客户端要用类名来修饰这些常量名，例如PhysicalConstants.AVOGADROS_NUMBER。如果大量利用工具类导出的常量，可以通过利用静态导入（static import）机制。避免用类名来修饰常量名，不过静态导入机制是在java发行版本1.5中才引入的：

package example;
import static example.PhysicalConstants.*;
/**
 * Created by Jiang Meiwei on 2017/5/7.
 */
public class test {
    double atoms(double mols){
        return AVOGADROS_NUMBER * mols;
    }
}

总结：

• 简而言之，接口应该只被用来定义类型，他不应该被用来导出常量。

2、 类层次优于标签类

标签类，这里指类依据本身的某个属性，来确定类会产生不同的对象。很明显，这不符合类的单一职责原则。如：

public class Figure {

  enum Shape {
    RECTANGLE, CIRCLE
  }

  private Shape shape;

  /** rectangle fields*/
  private double length;
  private double widht;

  /** circle fields*/
  private double radius;

  /** constructor for circle*/
  Figure(int radius) {
    this.radius = radius;
  }

  /** constructor for rectangle*/
  Figure(int length, int width) {
    this.length = length;
    this.widht = width;
  }

  double area() {
    switch (shape) {
      case RECTANGLE:
        return length * widht;
      case CIRCLE:
        return Math.PI * radius * radius;
      default:
        throw new AssertionError();
    }
  }

}

以上代码表示，类Figure拥有length、width、radis和shape属性，且当shape为RECTANGLE的时候，只使用length和width属性，当shape为CIRCLE的时候，则使用radius属性。这里属性shape就相当于标签，用于区分类的不同。

这种标签类（tagged class）有着许多缺点。

• 他们中充斥着样板代码，包括枚举声明，标签域以及条件语句。
• 由于多个实现乱七八糟地挤在了单个类中，破坏了可读性。
• 内存占用增加了，因为实例承担着属于其他风格的不相关的域。
• 域不能做成是final的，除非构造器初始化了不相关的域，产生更多的样板代码。
• 构造器必须不借助编译器，来设置标签域，并初始化正确的数据域：
• 如果初始化了错误的域，程序就会在运行时失败。
• 无法给标签类添加风格，除非可以修改它的源文件。如果一定要添加风格，就必须记得给每个条件语句都添加一个条件，否则类就会在运行时失败。
• 最后，实例的数据类型没有提供任何关于其风格的线索，一句话，标签类过于冗长，容易出错，并且效率低下。

由于设计不符合单一职责原则，那我们按如下步骤进行重构：

• 在标签类中选取依赖于标签的方法，提取作为抽象类的共同方法。这里就是area()方法。

public abstract class AbstractFigure {
  public abstract double area();
}

新建继承于抽象类的子类，并将特定标签相关的属性及方法移到该子类中。在这里，比如说当shape为CIRCLE时，特定相关的就是属性radius及构造方法。

public class CircleFigure extends AbstractFigure {

  private double radius;

  public CircleFigure(double radius) {
    this.radius = radius;
  }

  @Override
  public double area() {
    return Math.PI * radius * radius;
  }
}

public class RectangleFigure extends AbstractFigure {

  private double length;
  private double width;

  public RectangleFigure(double length, double width) {
    this.length = length;
    this.width = width;
  }

  @Override
  public double area() {
    return length * width;
  }
}

• 这段代码简单且清楚，没有包含在原来的版本中所见到的所有样板代码。
• 每个类型的实现都配有自己的类，这些类都没有受到不相关的数据域的拖累。
• 所有的域都是final的。
• 编译器确保每个类的构造器都初始化它的数据域，对于根类中声明的每个抽象方法，都确保有一个实现。这样就杜绝了由于遗漏switch case而导致运行时失败的可能性。
• 多个程序员可以独立的扩展层次结构，并且不用访问根类的源代码就能相互操作。每种类型都有一种相关的独立的数据类型，允许程序员指明变量的类型，限制变量，并将参数输入到特殊的类型。

类层次的另一种好处在于，他们可以用来反映类型之间本质上的层次关系，有助于增强灵活性，并进行更好地编译时类型检查。

总结：

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