设计模式学习笔记 - 面向对象 - 7.为什么要多用组合少用继承?如何决定该用组合还是继承?

前言

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

为什么不推荐使用继承?

组合比继承有哪些优势?

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

在这里插入图片描述


为什么不推荐使用继承?

继承是面向对象的四大特性之一,用来表示 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,这不就可以了吗?
在这里插入图片描述
上图中,可以看出,继承关系变成了三层。不过,整体上来讲,目前的继承关系还比较简单,层次比较浅。如果在加点难度,在刚刚的场景中,我们只关注鸟会不会非。但是,如果我们还关注“鸟会不会叫”,这个时候又该如何设计类之间的继承关系呢?

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

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

沿用上面的思路,那么还需要再定义四个抽象类:AbstractFlyableTweetableBirdAbstractFlyableUnTweetableBirdAbstractUnFlyableTweetableBirdAbstractUnFlyableUnTweetableBird
在这里插入图片描述
如果还要关注:是否会下蛋,那估计组合就要爆炸了。类的继承层次会越来越深、继承关系会越来越复杂。这会导致两个方面的问题:

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

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

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

组合比继承有哪些优势?

实际上,我们可以利用组合(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() 方法,并且实现逻辑一样,这会导致代码重复。

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

  • 实现 FlyableFlyAbility
  • 实现 TweetableTweetAbility
  • 实现 EggLayableEggLayAbility

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

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 关系、支持多态、代码复用。而在三个作用可以通过组合、接口、委托三个技术手段来达成。此外,利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。

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

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

  • 23
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值