6、组合 VS 继承

在面向对象编程中，有一条非常经典的设计原则，那就是：组合优于继承，多用组合少用继承
为什么不推荐使用继承？组合相比继承有哪些优势？如何判断该用组合还是继承？

1、为什么不推荐使用继承

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

1.1、示例

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

我们知道，大部分鸟都会飞，那我们可不可以在 AbstractBird 抽象类中，定义一个 fly() 方法呢
答案是否定的，尽管大部分鸟都会飞，但也有特例，比如鸵鸟就不会飞
鸵鸟继承具有 fly() 方法的父类，那鸵鸟就具有 "飞" 这样的行为，这显然不符合我们对现实世界中事物的认识
你可能会说，我在鸵鸟这个子类中重写（override）fly() 方法，让它抛出 UnSupportedMethodException 异常不就可以了吗

public class AbstractBird {

    // ... 省略其他属性和方法 ...

    public void fly() { ... }
}

// 鸵鸟
public class Ostrich extends AbstractBird {

    // ... 省略其他属性和方法 ...

    @Override
    public void fly() {
        throw new UnSupportedMethodException("I can't fly.'");
    }
}

1.2、问题

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

你可能又会说，那我们再通过 AbstractBird 类派生出两个更加细分的抽象类：会飞的鸟类 AbstractFlyableBird 和不会飞的鸟类 AbstractUnFlyableBird
让麻雀、乌鸦这些会飞的鸟都继承 AbstractFlyableBird，让鸵鸟、企鹅这些不会飞的鸟都继承 AbstractUnFlyableBird 类，不就可以了吗

从图中我们可以看出，继承关系变成了三层，不过整体上来讲，目前的继承关系还比较简单，层次比较浅，也算是一种可以接受的设计思路。我们再继续加点难度
在刚刚这个场景中，我们只关注 "鸟会不会飞"，但如果我们还关注 "鸟会不会叫"，那这个时候，我们又该如何设计类之间的继承关系呢？
是否会飞？是否会叫？两个行为搭配起来会产生四种情况：会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫
如果我们继续沿用刚才的设计思路，那就需要再定义四个抽象类
AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、AbstractUnFlyableTweetableBird、AbstractUnFlyableUnTweetableBird

如果我们还需要考虑 "是否会下蛋" 这样一个行为，那估计就要组合爆炸了，类的继承层次会越来越深、继承关系会越来越复杂

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

总之，继承最大的问题就在于：继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性，这也是为什么我们不推荐使用继承
那刚刚例子中继承存在的问题，我们又该如何来解决呢？你可以先自己思考一下，再听我下面的讲解

2、组合相比继承有哪些优势

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

2.1、示例

我们前面讲到接口的时候说过，接口表示具有某种行为特性

针对 "会飞" 这样一个行为特性，我们可以定义一个 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 implements Flayable, Tweetable, EggLayable {

    // ... 省略其他属性和方法 ...

    @Override
    public void fly() { ... }

    @Override
    public void tweet() { ... }

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

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

2.2、问题

我们可以针对三个接口再定义三个实现类
它们分别是：实现了 fly() 方法的 FlyAbility 类、实现了 tweet() 方法的 TweetAbility 类、实现了 layEgg() 方法的 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 tweet() {
        tweetAbility.tweet();   // 委托
    }

    @Override
    public void layEgg() {
        eggLayAbility.layEgg(); // 委托
    }
}

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

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

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

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

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

如果类之间的继承结构稳定（不会轻易改变），继承层次比较浅（最多有两层继承关系），继承关系不复杂，我们就可以大胆地使用继承
系统越不稳定，继承层次很深，继承关系复杂，我们就尽量使用组合来替代继承
除此之外，还有一些设计模式会固定使用继承或者组合
装饰者模式（decorator pattern）、策略模式（strategy pattern）、组合模式（composite pattern）等都使用了组合关系
模板模式（template pattern）使用了继承关系

前面我们讲到继承可以实现代码复用，利用继承特性，我们把相同的属性和方法，抽取出来，定义到父类中，子类复用父类中的属性和方法，达到代码复用的目的
但有的时候，从业务含义上，A 类和 B 类并不一定具有继承关系

3.1、示例 1

比如 Crawler 类和 PageAnalyzer 类，它们都用到了 URL 拼接和分割的功能，但并不具有继承关系（既不是父子关系，也不是兄弟关系）
仅仅为了代码复用，生硬地抽象出一个父类出来，会影响到代码的可读性
如果不熟悉背后设计思路的同事，发现 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();
    }

    // ...
}

3.2、示例 2

还有一些特殊的场景要求我们必须使用继承

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

// feighn client 框架代码
public class FeignClient {

    // ... 省略其他代码 ...

    public void encode(String url) { ... }
}

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

// Customized 自定义的
public class CustomizedFeignClient extends FeignClient {
    @Override
    public void encode(String url) { ... 重写 encode 的实现 ... }
}

// 调用
FeignClient client = new CustomizedFeignClient();
demofunction(client);

posted @ 2023-06-24 17:07 lidongdongdong~ 阅读(30) 评论(0) 编辑收藏举报

刷新页面返回顶部

lidong