本文结合《Effective Java》第四章条目16《复合优先于继承》和自己的理解及实践，讲解了Java继承机制的缺陷和替代方案，文章发布于专栏Effective Java，欢迎读者订阅。

继承的缺陷

继承的缺陷是由它过于强大的功能所导致的。继承使得子类依赖于超类的实现，从这一点来说，就不符合封装的原则。

一旦超类随着版本的发布而有所变化，子类就有可能遭到破坏，即使它的代码完全没有改变。

为了说明的更加具体，假设我们现在程序中使用到了HashSet，我们需要增加一个功能，去统计这个HashSet自创建以来一共曾经添加过多少元素。

在还不知道继承的缺陷的情况下，我们设计了一个类，继承了HashSet，添加了一个属性addCount来进行统计，并且复写了add和addAll方法，在方法里面修改addCount的值，代码如下：

public class InstrumentedHashSet<E> extends HashSet<E> {
// The number of attempted element insertions
private int addCount = 0;
public InstrumentedHashSet() {
}
public InstrumentedHashSet(int initCap, float loadFactor) {
super(initCap, loadFactor);
}
@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);
}
public int getAddCount() {
return addCount;
}
}

public static void main(String[] args) {
InstrumentedHashSet<String> s =
new InstrumentedHashSet<String>();
s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));
System.out.println(s.getAddCount()); // expect 3 but 6
}

其实，在HashSet内部，addAll方法是基于add方法来实现的，因此，使用addAll添加三个元素，会调用一次addAll，三次add。

再看看我们复写的方法，也就明白为什么getAddCount返回6了。

当然，你会说，既然HashSet是这样实现的，那么我们就不要复写addAll方法就行了。是的，没错。

但是这样虽然可以正常工作，但是它的正确性却依赖于这样的事实：HashSet的addll方法是在add方法上实现的。

一旦超类修改了实现细节，我们的功能就会有可能受影响。

总的来说，继承存在三个天然缺陷，这些缺陷会导致软件非常脆弱：

1） 子类如果调用了父类的方法，那么就会对父类形成依赖，一旦父类做了改动，子类就很可能不能正常工作。

2） 如果父类新增了方法，而子类恰好已经提供了一个签名相同但是返回值不同的方法，那么子类将无法通过编译。

3） 在不应该继承的时候使用继承，会暴露不必要的API给子类。这一点，Java平台就犯过错，典型的例子就是Properties继承了HashTable，这是不合理的，属性列表不是散列表，但是Java代码里的Properties却继承了HashTable，导致用户创建Properties实例后，有put和setProperties两个方法，有get和getProperties两个方法，而put和get方法是不应该给用户暴露的。

因为在Properties里，key和value都应该是String，而HashMap可以是其他类型甚至是对象。

public class TestProperty {
public static void main(String[] args) {
Properties properties = new Properties();
properties.setProperty("aaa", "aaa");
properties.put("aaa", new TestPropertyObj());
System.out.println(properties.getProperty("aaa")); // null
System.out.println(properties.get("aaa")); // com.hzy.effjava.chp3.item16.TestProperty$TestPropertyObj@5f4fcc96
}
static class TestPropertyObj {
}
}

复合  继承的替代方案

上一节讲了继承的缺陷，这一节就让我们来看看解决这个问题的方案——复合。

首先我们需要一个持有Set对象的一个类，这个类实现了Set接口，实现方法里调用了所持有的Set对象的对应的方法，因此我们也叫它转发类：

public class ForwardingSet<E> implements Set<E> {
private final Set<E> s;
public ForwardingSet(Set<E> s) { this.s = s; }
public void clear()
{ s.clear();
}
public boolean contains(Object o) { return s.contains(o); }
public boolean isEmpty()
{ return s.isEmpty();
}
public int size()
{ return s.size();
}
public Iterator<E> iterator()
{ return s.iterator();
}
public boolean add(E e)
{ return s.add(e);
}
public boolean remove(Object o)
{ return s.remove(o);
}
public boolean containsAll(Collection<?> c)
{ return s.containsAll(c); }
public boolean addAll(Collection<? extends E> c)
{ return s.addAll(c);
}
public boolean removeAll(Collection<?> c)
{ return s.removeAll(c);
}
public boolean retainAll(Collection<?> c)
{ return s.retainAll(c);
}
public Object[] toArray()
{ return s.toArray();
}
public <T> T[] toArray(T[] a)
{ return s.toArray(a); }
@Override public boolean equals(Object o)
{ return s.equals(o);
}
@Override public int hashCode()
{ return s.hashCode(); }
@Override public String toString() { return s.toString(); }
}

public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;
    public InstrumentedSet(Set<E> s) {
        super(s);
    }
    @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);
    }
    public int getAddCount() {
        return addCount;
    }
    public static void main(String[] args) {
        InstrumentedSet<String> s =
            new InstrumentedSet<String>(new HashSet<String>());
        s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));    
        System.out.println(s.getAddCount());
    }
}

而且这样写还有一个好处，这个类可以给所有实现了Set接口的类添加统计功能，而不仅仅是HashSet，还包括TreeSet等其他Set。

其实，这就是装饰模式，InstrumentedSet对Set进行了修饰，给它增加了计数属性。

总结

继承会破坏类的封装性，导致子类非常脆弱，容易受到破坏。

使用复合的方式，对超类进行修饰，使得子类更加的健壮，同时功能更加强大。

最后

以上就是俭朴宝马为你收集整理的Java 比继承更好的一种机制 —— 复合继承的缺陷复合  继承的替代方案总结的全部内容，希望文章能够帮你解决Java 比继承更好的一种机制 —— 复合继承的缺陷复合  继承的替代方案总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。