前言

在面向对象编程中，有一条非常经典的设计原则：组合优于继承，多用组合少用继承。

为什么不推荐使用继承？

组合比继承有哪些优势？

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

---

为什么不推荐使用继承？

继承是面向对象的四大特性之一，用来表示 is-a 的关系，可以解决代码复用问题。虽然继承有诸多作用，但继承层次太深、过于复杂，会影响到代码的可维护性。所以对弈是否应该在项目中使用继承，有很多争议，很多人觉得继承是一种反模式，应尽量少用。为什么会有这样的争议，我们聚类自来说明下。

假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念，定义为一个抽象类 AbstractBird。所有细分的鸟，比如麻雀、鸽子、乌鸦等，都继承这个类。

大部分鸟可以飞，那可以在 AbstractBird 抽象类里面定义一个 fly() 方法吗？答案是否定的。尽管大部分鸟会飞，但也有特例，比如鸵鸟就不会飞。鸵鸟继承具有 fly() 方法的父类，就具有了“飞”这样的行为，这显然不符合我们的对现实世界的认识。当然，你可能会说，我在鸵鸟这个子类中重写 fly() 方法，让它们抛出 UnSupportedMethodException 异常不就可以了吗？代码如下：

public class AbstractBird {
	// 省略其他属性和方法...
	public void fly() { /*...*/ }
}

public class Ostrich extends AbstractBird {
	// 省略其他属性和方法...
	@Override
	public void fly() {
		throw new UnSupportedMethodException("I can't fly.");
	}
}

这种设计思路虽然可以解决问题，但不够优美。因为除了鸵鸟，不会飞的鸟类还有很多，如企鹅。对于这些不会飞的鸟，都要重写 fly() 方法，抛出异常。这样的设计，一方面增加了编码的工作量；另一方面，也违背了我们之后要讲解的最小知识原则（最少知识原则，也叫迪米特法则），暴露不该暴露的接口给外部，增加了类适用过程中被误用的概率。

可能你又会说，可以给 AbstractBird 在派生出两个更加细分的抽象类：会飞的鸟 AbstractFlyableBird 和不会飞的鸟AbstractUnFlyableBird，让会飞的鸟继承 AbstractFlyableBird ，不会飞的鸟继承AbstractUnFlyableBird，这不就可以了吗？

上图中，可以看出，继承关系变成了三层。不过，整体上来讲，目前的继承关系还比较简单，层次比较浅。如果在加点难度，在刚刚的场景中，我们只关注鸟会不会非。但是，如果我们还关注“鸟会不会叫”，这个时候又该如何设计类之间的继承关系呢？

是否会飞？是否会叫？连个行为搭配起来会产生四种情况：

• 会飞会叫
• 会飞不会叫
• 不会飞会叫
• 不会飞不会叫

沿用上面的思路，那么还需要再定义四个抽象类：AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、AbstractUnFlyableTweetableBird、AbstractUnFlyableUnTweetableBird。

如果还没还要关注：是否会下蛋，那估计组合就要爆炸了。类的继承层次会越来越深、继承关系会越来越复杂。这会导致两个方面的问题：

• 一方面，代码的可读性变差。我们要搞清楚类具有哪些属性和方法，必须阅读父类的代码、父类的父类的代码…，一直追溯到顶层父类的代码。
• 另一方面，也破坏了类的封装特性，将父类的实现细节暴露给了子类。子类的实现依赖父类的实现，两者高度耦合，一旦父类代码修改，就影响所有子类的逻辑。

所以，继承最大的问题在于：继承层次过深、继承关系过于复杂，会影响到代码的可读性和可维护性。这也是为什么不推荐使用继承的原因。

那这个问题又该如何解决呢？

组合比继承有哪些优势？

实际上，我们可以利用组合（composition）、接口、委托类（delegation）三个技术手段，一块来解决刚刚继承存在的问题。

接口表示具有某些特性的行为。针对会飞这样的特性，可以定义一个 Flyable 接口，只会让会飞的鸟去实现这个接口。对于会叫、会下蛋这些行为，我们可以类似的定义 Tweetable 接口和 EggLayable 接口。下面是具体的例子。

public interface Flyable {
	void fly();
}

public interface Tweetable {
	void tween();
}

public interface EggLayable{
	void layEgg();
}

// 鸵鸟
public class Ostrich implements Tweetable, EggLayable {
	// 其他属性方法省略...
	@Override
	public void tween() { /*...*/ }
	@Override
	public void layEgg() { /*...*/ }
}

// 麻雀
public class Sparrow implements Flyable, Tweetable, EggLayable {
	// 其他属性方法省略...
	@Override
	public void fly() { /*...*/ }
	@Override
	public void tween() { /*...*/ }
	@Override
	public void layEgg() { /*...*/ }
}

只是，只生命接口，不定义实现的话，每个会下蛋的鸟都要实现一遍 layEgg() 方法，并且实现逻辑一样，这会导致代码重复。

我们可以针对这三个接口再定义三个实现类，分别是：

• 实现 Flyable 的 FlyAbility 类
• 实现 Tweetable 的 TweetAbility 类
• 实现 EggLayable 的 EggLayAbility 类

然后通过组合和委托技术来消除代码重复。具体代码如下：

public interface Flyable {
	void fly();
}

public class FlyAbility implements Flyable {
	// 其他属性方法省略...
	@Override
	public void fly() { /*...*/ }
}
// 省略Tweetable/TweetAbility/EggLayable/EggLayAbility

public class Ostrich implements Tweetable, EggLayable {
	private TweetAbility tweetAbility = new TweetAbility();
	private EggLayAbility eggLayAbility = new EggLayAbility();

	// 其他属性方法省略...
	@Override
	public void tween() {
		tweetAbility.tween(); // 委托
	}
	@Override
	public void layEgg() {
		eggLayAbility.layEgg(); // 委托
	}
}

我们知道继承主要有三个作用：表示 is-a 关系，支持多态特性，代码复用。而这三个作用都可以通过其他技术手段来达成。

• is-a 关系：通过组合和接口的 has-a 关系来替代；
• 多态特性：利用接口来实现
• 代码复用：通过组合和委托来实现。

所以，理论上，通过组合、接口、委托三个技术手段，完全可以替换掉继承，在项目中不用或者少用继承关系，特别是一些复杂的继承关系。

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

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

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

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

前面我们讲过继承可以实现代码复用。利用继承特性，可以把相同的属性和方法，抽取出来，定义到父类中。子类复用父类的属性和方法，达到代码复用的目的。但是，有时候，从业务含义上，A 类和 B 类并一定具有继承关系。比如 Crawler 类和 PageAnalyzer 类，它们都用到了 URL 拼接和分割的功能，但并不具有继承关系（既不是父子，也不是兄弟）。仅仅为了代码复用，生硬地抽象出一个父类出来，会影响代码地可读性。这个时候，使用组合就更加合理、灵活。

public class Url {
	// 省略属性和方法...
}

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

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

如果有些场合要求必须使用继承。如果你不能改变一个函数的入参类型，而入参非接口，为了支持多态，只能采用继承来实现。比如下面的代码，其中 FeignClient 是一个外部类，我们没有权限去修改这部分代码，但是我们希望重写这个类在运行时执行的 encode() 函数。这个时候，我们只能采用继承实现了。

public class FeignClient {
	// 省略其他代码...
	public void encode(String url) { /*...*/ }
}

public void demoFuction(FeignClient feignClient) {
	// ...
	feignClient.encode(url);
	// ...
}

public class CustomizeFeignClient extend FeignClient {
	@Override
	public void encode(String url) { /*重写encode的实现...*/ }
}

// 调用
FeignClient client = new CustomizeFeignClient();
demoFuction(client);

尽管有些人，要杜绝继承，100% 用组合代替继承，但是我们可以不需要这么极端。之所以“多用组合少用继承”这个口号喊的响，只是因为，长期以来，我们过度使用继承。还是那句话，组合并不完美，继承也不是一无是处。只要我们控制好它的副作用、发挥它们各自的优势，在不同的场合下，恰当地选择使用组合还是继承，这才应该追求的境界。

总结

为什么不推荐使用继承？

继承是面向对象的四大特性之一，用来表示 is-a 的关系，可以解决代码复用的问题。虽然，继承的作用很多，但是继承层次太深、过复杂，也会影响到代码的可维护性。在这种情况下，应尽量少用，甚至不用继承。

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

继承主要有三个优势：表示 is-a 关系、支持多态、代码复用。而在三个作用可以通过组合、接口、委托三个技术手段来达成。初次之外，利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。

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

在开发中需要根据情况来选择。如果类之间的继承结构稳定、层次比较浅、关系不复杂，那就可以大胆地使用继承。反之，就尽量使用组合来替代继承。初次之外，一些设计模式、特殊的场景，会固定使用继承或者组合。