为何说要多用自核少用继承？如何决定该用组合还是继承？

组合（composition）、接口（interface）、委托（delegation）

public interface Flyable {
  void fly();
}

public interface Tweetable {
  void tweet();
}

public interface EggLayable {
  void layEgg();
}

public class FlyAbility implements Flyable {

  @Override
  public void fly() {

  }
}

public class TweetAbility implements Tweetable {

  @Override
  public void tweet() {

  }
}

public class EggLayability implements EggLayable {

  @Override
  public void layEgg() {

  }
}

public class Ostrich implements Tweetable, EggLayable {
  private final TweetAbility tweetAbility = new TweetAbility(); // composition
  private final EggLayability eggLayability = new EggLayability();


  @Override
  public void tweet() {
    tweetAbility.tweet(); // delegation
  }

  @Override
  public void layEgg() {
    eggLayability.layEgg();
  }
}

我们知道继承主要有三个作用：表示is-a关系，支持多态继承，代码复用。而这三个作用都可以通过其他技术手段来达成。比如is-a关系，我们可以通过组合和接口的behave-like关系来替代；多态特性我们可以利用接口来实现；代码复用我们可以通过组合和委托来实现。所以，从理论上来讲，通过组合、接口、委托三个技术手段，我们完全可以替换掉继承，在项目中不用或者少用继承关系，特别是一些复杂的继承关系。

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

尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。从上面的例子来看，继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着，我们要定义更多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。所以，在实际的项目开发中，我们还是要根据具体的情况，来具体选择该用继承还是组合。

如果类之间的继承结构稳定（不会轻易改变），继承层次比较浅（比如，最多有两层继承关系），继承关系不复杂，我们就可以大胆地使用继承。反之，系统越不稳定，继承层次很深，继承关系复杂，我们就尽量使用组合来替代继承。

除此之外，还有一些设计模式会固定使用继承或者组合。比如，装饰者模式（decorator pattern），策略模式（strategy pattern）、组合模式（composite pattern）等都使用了组合关系，而模板模式（template pattern）使用了继承关系。

前面我们讲到继承可以实现代码复用。利用继承特性，我们把相同的属性和方法，抽取出来，定义到父类中。族类复用父类中的属性和方法，达到代码复用的目的。但是，有的时候，从业务含义上，A类和B类并不一定具有继承关系。比如，Crawler类和PageAnalyzer类，它们都用到了URL拼接和分割的功能，但并不具有继承关系（既不是父子关系，也不是兄弟关系）。仅仅为了代码复用，生硬的抽象出一个父类出来，会影响到代码的可读性。如果不熟悉背后设计思路的同时，发现Crawler类和PageAnalyzer类继承同一个父类，而父类中定义的却只是URL相关的操作，会觉得这个代码写得莫名其妙，理解不了。这个时候，使用组合就更加合理、更加灵活。具体的代码实现如下所示：

public class Url {
  // omit attributes and methods
}

public class Crawler {
  private final Url url; //composition

  public Crawler() {
    this.url = new Url();
  }
  // ...
}

public class PageAnalyzer {
  private final Url url; // composition

  public PageAnalyzer() {
    this.url = new Url();
  }
  // ...
}

小结与回顾

为什么不推荐使用继承？

继承是面向对象的四大特性之一，用来表示类之间的is-a关系，可以解决代码复用的问题。虽然继承有诸多作用，但继承层次过深、过复杂，也会影响到代码的可维护性。在这种情况下，我们应该尽量少用，甚至不用继承。
组合相比继承有哪些优势？

继承主要有三个作用：表示is-a关系，支持多态特性，代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。除此之外，利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。
如何判断该用组合还是继承？（尽量使用接口、组合和委托代替继承，不要使用继承）

尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。在实际的项目开发中，我们还是要根据具体的情况，来选择该用继承还是组合。如果类之间的继承结构稳定，层次比较浅，关系不复杂，我们就可以大胆地使用继承。反之，我们就尽量使用组合来替代继承。除此之外，还有一些设计模式、特殊的应用场景，会固定使用继承或者组合。

（新的编程语言让接口+组合+委托变得容易，例如Kotlin就有专门的语法糖支持，消除了很多模板代码。）

（接口+组合+委托符合矢量化思想，那就是将物体特征分成不同的维度，每个维度独立变化。继承则是将物体分裂，抽取共性，处理共性，操作的灵活性大打折扣，毕竟现实中的物体特征多，共性少。）