浅谈复合优于继承

继承的不安全性

    在包内进行继承时和在继承专为继承而设计的超类时是安全的，但是继承一些设计初衷并不是为了继承而涉及的类时就不安全了，因为这种类可能在后面的版本中发生变化，如添加新的方法，这个方法可能会与子类中的已有方法冲突，比如子类中有 int getBirthYear（）方法，而在新的超类中有一个 String getBirthYear（）方法，这样就会直接导致编译不通过；还有就是超类修改了原有方法的实现，而子类中的某些方法依赖于原超类中方法实现中的某些约定，而新的超类中该约定被打破了，那么虽然不会导致编译不通过，但是却会导致结果异常。 

适用“复合”的情况

    由于上面出现的继承不安全性，“复合”必要性就体现出来了。复合通过转发的方式将子类的操作通过转发类转发到具体的接口实现类。适用复合的情况有：
    1. 子类真正的超类并非当前继承的超类时（两个类之间时has关系而不是is关系）
    2. 如果当前继承的超类中有缺陷，同时也不愿将该缺陷继承到子类中去        

复合的实质

    复合的实质就是新建一个转发类超类进行包装，使超类与转发类呈has关系——转发类has超类。而这个包装过程就是实现超类所实现的接口，对接口中声明的方法进行代理转发。这个过程起到切断被包装类和子类中的is关系，使子类的方法不再依赖超类中的具体方法实现和一些约定。

复合中的设计模式

    代理模式（Proxy)：为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。在这里转发类就是代理类（proxy class);转发类实现的接口就是抽象角色（abstract role);该接口的实现其他实现就是真实角色（real role)。
    装饰模式（Decorator）：在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。在这几转发类的子类就是包装类（wrapper class)，包裹着代理模式中的真实角色。

接口多继承在复合中的体现

    开始我还有疑问在设计者对当前转发类的接口进行了扩展，那么怎么保证当前的转发类的正确性，后来看到一篇文章上说到这个问题，就是接口是可以多继承的，一般不会对接口本身就行修改，而是新增接口达到对先有接口进行扩展。这也就需要代码设计者遵守不修改现有接口而采用新增接口进行接口扩展的代码规范了。