0、 非常经典的设计原则: 组合优于继承，多用组合少用继 承

1、 为什么不推荐使用继承 ?

继承虽然可以解决代码复用性问题,但是继承层次过深,过复杂,也会影响到代码的可维护性,所以 如下图举例鸵鸟、企鹅、乌鸦、麻雀鸟根据共性要拆分成可飞的鸟，不可飞的鸟.这样是不是很复杂，关系臃肿，如何改造了？这样耦合度是不是很高，不符合我们的高类聚、低耦合的标准

如何解决这个问题，我们改为组合模式哈？
如何实现了？
用组合（composition）、接口、委托（delegation）三个技术手 段 ？本质是抽取、拆分的过程？

比如抽取出会飞、下蛋这样的接口抽取的共性我们一般用接口，只要关注公用，不用关注实现细节如下图(采用多实现而非继承的方法)

问题又来了，多重实现是不是还是会导致代码代码重复写，接口只是声明，实现细节还是要(组合就是)

如上图其实就是将所有的方法、接口、抽取组合公共调用（还是比较抽象就是全部抽取成公共的方法调用了）

2、 组合相比继承有哪些优势？

组合（composition）、接口、委托（delegation）三个技术手 段，一块儿来解决刚刚继承存在的问题 ， 通过组合和委托技术来消除代码重复 ,代码复用我们可以通过组合和委托来实现。所 以，从理论上讲，通过组合、接口、委托三个技术手段，我们完全可以替换掉继承，在项目 中不用或者少用继承关系，特别是一些复杂的继承关系 .

3、 如何判断该用组合还是继承？

继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着，我们要定义更 多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。所以，在 实际的项目开发中，我们还是要根据具体的情况，来具体选择该用继承还是组合 , 如果类之间的继承结构稳定（不会轻易改变），继承层次比较浅（比如，最多有两层继承关 系），继承关系不复杂，我们就可以大胆地使用继承。反之，系统越不稳定，继承层次很 深，继承关系复杂，我们就尽量使用组合来替代继承。
说穿了主要那种代码少用那种哈