组合还是继承
假设我们要统计set的历史元素数。
1. 定义一个类，申明一个静态成员变量作为计数器，尝试重写add和addAll方法，计数器增加。
发现数量统计是预期的2倍，因为addAll里面调用了add，被两次计数。
如果之重写add，假如addAll以后的发布版本中不调用了add了怎么办。如果把addAll全部重写，那么父类的实现被架空。假如为了保证安全，父类在元素加入之前做检查，我们架空的方法就很危险。
2. 如果父类新增了一个方法，签名和你子类中的一个方法一样，但是返回值不一样，傻眼了，编译通不过。
3. 咋整，用组合模式
新建前置类实现set接口，同时定义一个set的成员变量，继承方法实现调用成员变量的方法。
创建工具类 再扩展前置类，实现计数。就是装饰器模式。
这种玩法和委托有所区别，在于包装的东西和自己有没有关系
还有在回调场景下，不适合。
4.适合用组合却用了继承，比如Properties继承了HashTable，Stack继承了Vector。
Properties对象实例p 可以调用父类的getKey()得到一个很粗糙的值，而且Properties设计的时候只支持String，但是p调用父类的put，随便什么都可以放进去，很乱套。
所以只有 在确定A肯定是B的时候，A再去继承B。
