为何说JAVA中要慎重使用继承

这篇文章的主题并不是鼓励不使用继承，而是仅从使用继承带来的问题出发，讨论继承机制不太好的地方，从而在使用时慎重选择，避开可能遇到的坑。

JAVA中使用到继承就会有两个没法回避的缺点：

1. 打破了封装性，子类依赖于超类的实现细节，和超类耦合。
2. 超类更新后可能会致使错误。

继承打破了封装性

关于这一点，下面是一个详细的例子（来源于Effective Java第16条）

public class MyHashSet<E> extends HashSet<E> {
    private int addCount = 0;

    public int getAddCount() {
        return addCount;
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }
}

这里自定义了一个HashSet，重写了两个方法，它和超类惟一的区别是加入了一个计数器，用来统计添加过多少个元素。

写一个测试来测试这个新增的功能是否工做：

public class MyHashSetTest {
    private MyHashSet<Integer> myHashSet = new MyHashSet<Integer>();

    @Test
    public void test() {
        myHashSet.addAll(Arrays.asList(1,2,3));
        
        System.out.println(myHashSet.getAddCount());
    }
}

运行后会发现，加入了3个元素以后，计数器输出的值是6。

进入到超类中的addAll()方法就会发现出错的缘由：它内部调用的是add()方法。因此在这个测试里，进入子类的addAll()方法时，数器加3，而后调用超类的addAll()，超类的addAll()又会调用子类的add()三次，这时计数器又会再加三。

问题的根源

将这种状况抽象一下，能够发现出错是由于超类的可覆盖的方法存在自用性(即超类里可覆盖的方法调用了别的可覆盖的方法)，这时候若是子类覆盖了其中的一些方法，就可能致使错误。

好比上图这种状况，Father类里有可覆盖的方法A和方法B，而且A调用了B。子类Son重写了方法B，这时候若是子类调用继承来的方法A，那么方法A调用的就再也不是Father.B()，而是子类中的方法Son.B()。若是程序的正确性依赖于Father.B()中的一些操做，而Son.B()重写了这些操做，那么就极可能致使错误产生。

关键在于，子类的写法极可能从表面上看来没有问题，可是却会出错，这就迫使开发者去了解超类的实现细节，从而打破了面向对象的封装性，由于封装性是要求隐藏实现细节的。更危险的是，错误不必定能轻易地被测出来，若是开发者不了解超类的实现细节就进行重写，那么可能就埋下了隐患。

超类更新时可能产生错误

这一点比较好理解，主要有如下几种可能：

• 超类更改了已有方法的签名。会致使编译错误。
• 超类新增了方法：
  • 和子类已有方法的签名相同但返回类型不一样，会致使编译错误。
  • 和子类的已有方法签名相同，会致使子类无心中复写，回到了第一种状况。
  • 和子类无冲突，但可能会影响程序的正确性。好比子类中元素加入集合必需要知足特定条件，这时候若是超类加入了一个无需检测就能够直接将元素插入的方法，程序的正确性就受到了威胁。

设计可继承的类

设计能够用来继承的类时，应该注意：

• 对于存在自用性的可覆盖方法，应该用文档精确描述调用细节。
• 尽量少的暴露受保护成员，不然会暴露太多实现细节。
• 构造器不该该调用任何可覆盖的方法。

详细解释下第三点。它实际上和 继承打破了封装性 里讨论的问题很类似，假设有如下代码：

public class Father {
    public Father() {
        someMethod();
    }

    public void someMethod() {
    }
}

public class Son extends Father {
    private Date date;

    public Son() {
        this.date = new Date();
    }

    @Override
    public void someMethod() {
        System.out.println("Time = " + date.getTime());
    }
}

上述代码在运行测试时就会抛出NullPointerException ：

public class SonTest {
    private Son     son = new Son();

    @Test
    public void test() {
        son.someMethod();
    }
}

由于超类的构造函数会在子类的构造函数以前先运行，这里超类的构造函数对someMethod()有依赖，同时someMethod()被重写，因此超类的构造函数里调用到的将是Son.someMethod()，而这时候子类还没被初始化，因而在运行到date.getTime()时便抛出了空指针异常。

所以，若是在超类的构造函数里对可覆盖的方法有依赖，那么在继承时就可能会出错。

结论

继承有不少优势，但使用继承时应该慎重并多加考虑。一样用来实现代码复用的还有复合，若是使用继承和复合皆可(这是前提)，那么应该优先使用复合，由于复合能够保持超类对实现细节的屏蔽，上述关于继承的缺点均可以用复合来避免。这也是所谓的复合优先于继承。

若是使用继承，那么应该留意重写超类中存在自用性的可覆盖方法可能会出错，即便不进行重写，超类更新时也可能会引入错误。同时也应该精心设计超类，对任何相互调用的可覆盖方法提供详细文档。