《设计模式之美》理论七：为何说要多用组合少用继承？如何决定该用组合还是继承？

王争《设计模式之美》学习笔记

为什么不推荐使用继承？

1. 文中作者以鸟类举例，里面有一个fly的方法，各种类型的鸟都继承这个鸟类。
2. 那么当有不会飞的鸟比如鸵鸟来继承这个鸟类的时候，就要重写fly方法，方案并不优雅。多个不会飞的鸟来继承鸟类的时候，每个都要重写，问题就更突出了。
3. 换个思路的话，在鸟类下面再设计两个子类，会飞鸟类和不会飞鸟类，让会飞的鸟和不会飞的鸟分别继承，三级层级。看似还算融洽。
4. 按照以上这个思路，鸟还分会叫的不会叫的，会下蛋的不会下蛋的，这样一组合，简直就是灾难乱套。
5. 总结，继承最大的问题就在于：继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性。

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

1. 文中作者改造上面鸟类的例子，首先封装会飞、会叫、会下蛋这样的三个接口。
2. 然后再给三个接口定义三个实现类，解决重复实现逻辑的问题，达到代码复用。
3. 鸵鸟会叫、会下蛋：
   1. 鸵鸟类先实现先会叫、会下蛋两个接口。
   2. 在类中有会叫、会下蛋两个属性，这两个属性分别是实例化会叫、会下蛋两个实现类，这是组合的运用。
   3. 在类中有会叫、会下蛋的两个方法，这两个方法分别是实现类中的方法来实现的，这是委托的运用。
4. 总结，可以利用组合、接口、委托三个技术手段，来解决继承存在的问题。

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

1. 如果类之间的继承结构稳定（不会轻易改变），继承层次比较浅（比如，最多有两层继承关系），继承关系不复杂，我们就可以大胆地使用继承。
2. 系统越不稳定，继承层次很深，继承关系复杂，我们就尽量使用组合来替代继承。
3. 文中作者举例，A类和B类都用到了URL拼接和分割的功能，不能为了代码复用，硬抽象出来一个父类，可以用组合的方式实现。
4. 文中作者举例，当想修改一个外部类的方法时，我们没有权限修改这个外部类，只能继承这个外部类，以重写的方式修改其中的方法。
5. 我觉得作者对继承的举例有些局限性，继承还是有使用场景和使用空间。不过作者的思想不极端，只要不多度使用，继承还是可用的，这也是我喜欢看作者课程的原因。