美文网首页
学习笔记-为何说多用组合少用继承

学习笔记-为何说多用组合少用继承

作者: 家猪佩奇 | 来源:发表于2020-03-30 21:23 被阅读0次

在面向对象的编程中,有一条非常经典的设计原则:组合优于继承,多用组合少用继承。什么不推荐使用继承?组合比继承有哪些优势?

为什么不推荐使用继承?

继承是面相对象的四大特性之一,用来表示类之间的is-a关系,可以解决代码复用的问题。虽然继承有诸多作用,但继承层次过深、过复杂,也会影响到代码的可维护性。所以对于项目中是否应该使用继承有很多争议,很多人觉得继承是一种反模式,应该尽量少用,甚至不用。为什么会有这样的争议?我们通过一个例子来解释一下。

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

我们都知道,大部分鸟会飞,那我们可不可以在AbstractBird抽象类中,定义一个fly()方法呢?答案是否定的。尽管大部分鸟会飞,但也有特例,比如鸵鸟就不会飞。鸵鸟继承具有fly()方法的父类,那鸵鸟就具有“飞”的这样的行为,显然是不合情理的。当然你可能会说,在鸵鸟这个子类中重写(overwride)fly()方法,让它抛出UnsupportedMethodException异常不就可以了吗?具体的实现代码如下所示:

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

这种设计思路虽然可以解决问题,但不够优雅。因为除了鸵鸟之外,不会飞的鸟还有很多,比如企鹅。对于这些不会飞的鸟来说,我们都需要重写fly()方法,抛出异常。这样的设计,一方面徒增了编码的工作量;另一方面,也违背了我们所说的最小知识原则(Least Knowledge Principle,也叫最小知识原则或者迪米特法则),暴露不该暴露的接口给外部,增加类使用过程中被误用的概率。

你可能又会说,那我们再通过AbstractBird类派生出两个更加细分的抽象类:会飞的鸟类AbstractFlyableBird和不会飞的鸟类AbstractUnFlyableBird。继承关系如下图:



从整体上来看,继承关系比较简单,层次比较浅,也算一种可以接受的设计思路。那如果我们还关注“鸟会不会叫“,那这个时候我们又该如何设计类之间的继承关系呢?

是否会飞?是否会叫?这两个行为搭配起来就会产生四种情况。如果我们还需要关注“是否会下蛋”这样一个行为,那估计就要组合爆炸了。类的层次越来越深,继承关系越来越复杂。

总之,继承最大的问题就在于:继承层次过深,继承关系过于复杂影响到代码的可读性和可维护性。

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

实际上我们可以利用组合(composition)、接口、委托(delegation)三个技术手段一块来解决刚刚继承存在的问题。
接口表示具有某种行为特征。针对“会飞”这样一个行为特性,我们可以定义一个Flyable接口,只让会飞的鸟去实现这个接口。对于会叫,会下蛋这些行为特性,我们可以类似的定义Tweetable、EggLayable接口。就是下面这个样子:

public interface Flyable {
  void fly();
}
public interface Tweetable {
  void tweet();
}
public interface EggLayable {
  void layEgg();
}
public class Ostrich implements Tweetable, EggLayable {//鸵鸟
  //... 省略其他属性和方法...
  @Override
  public void tweet() { //... }
  @Override
  public void layEgg() { //... }
}
public class Sparrow impelents Flayable, Tweetable, EggLayable {//麻雀
  //... 省略其他属性和方法...
  @Override
  public void fly() { //... }
  @Override
  public void tweet() { //... }
  @Override
  public void layEgg() { //... }
}

不过,我们知道,接口只声明方法,不定义实现。也就是说每个会下蛋的鸟都要实现一遍layEgg()方法,并且实现逻辑都是一样的,这就导致代码重复的问题。如何解决呢?

我们可以针对三个接口再定义三个实现类,通过组合和委托技术来消除代码重复:

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 tweet() {
    tweetAbility.tweet(); // 委托
  }
  @Override
  public void layEgg() {
    eggLayAbility.layEgg(); // 委托
  }
}

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

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

如果类之间的继承结构稳定,不会轻易改变,继承层次比较浅,比如最多有两层继承关系,继承关系不复杂,我们就可以大胆的使用继承。

反之,系统越不稳定,继承层次很深,继承关系复杂,我们就尽量使用组合代替继承。

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

相关文章

  • 学习笔记-为何说多用组合少用继承

    在面向对象的编程中,有一条非常经典的设计原则:组合优于继承,多用组合少用继承。什么不推荐使用继承?组合比继承有哪些...

  • 多用组合少用继承

    不推荐使用继承 继承表示is-a的关系,用于代码复用。但是继承会增加代码的耦合,复杂的继承关系(层次过深,过于复杂...

  • (转)多用组合,少用继承

    最近在学习设计模式,发现一个好文作者:跳刀的兔子链接:https://www.cnblogs.com/shipen...

  • 面向对象原则

    组合复用原则 多用组合, 少用继承 , 用组合代替继承 ,比如在java 分层设计中, service需要用dao...

  • 10 - 深入理解组合&继承

    在面向对象编程中,有一条非常经典的设计原则,那就是:组合优于继承,多用组合少用继承。为什么不推荐使用继承?组合相比...

  • 面向对象:多用组合少用继承

    为什么不推荐使用继承? 虽然继承可以解决代码复用问题,但继承层次过深、过复杂,也会影响到代码的可维护性。 组合相比...

  • 面向对象(七)组合优于继承?

    组合优于继承,多用组合少用继承。 1、为什么不推荐使用继承? 继承是面向对象的四大特性之一,用来表示类之间的 is...

  • 设计模式总结

    1、模式依赖基础与原则 1.1、基础 抽象,封装,多态,继承 1.2、原则 封装变化,多用组合、少用继承,针对接口...

  • 设计模式要点

    OO指面向对象 OO基础 抽象 封装 多态 继承 OO原则 封装变化 多用组合,少用继承 针对接口编程,不针对实现...

  • Golang-TCP异步框架Tao分析

    TCP异步框架 Golang 编程风格 Go语言面向对象编程的风格是多用组合,少用继承,以匿名嵌入的方式实现继承。...

网友评论

      本文标题:学习笔记-为何说多用组合少用继承

      本文链接:https://www.haomeiwen.com/subject/abubuhtx.html