11.多用组合和少继承

目录介绍

• 01.前言思考的介绍

• 1.1 组合优于继承思考

• 1.2 实际中的案例

• 1.3 思考继承的争议

• 02.绘图应用程序案例

• 2.1 案例的背景

• 2.2 用继承实现多形状

• 2.3 用组合实现多形状

• 03.不同鸟类程序案例

• 3.1 案例的背景

• 3.2 用继承实现多鸟类

• 3.3 继承的问题暴露

• 3.4 用组合实现多鸟类

• 04.多组合少继承

• 4.1 组合 VS 继承

• 4.2 多组合少继承场景

• 4.3 多组合少继承原因

• 05.如何选择组合或继承

• 5.1 如何去选择

• 5.2 使用组合方式

• 5.3 使用继承方式

• 06.多组合少继承总结

01.前言思考的介绍

1.1 组合优于继承思考

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

为什么不推荐使用继承？组合相比继承有哪些优势？如何判断该用组合还是继承？

1.2 实际中的案例

策略模式：通过组合不同的策略对象，动态地改变算法或行为。

装饰者模式：通过组合多个装饰者对象，动态地为对象增加功能。

1.3 思考继承的争议

继承是面向对象的四大特性之一，用来表示类之间的 is-a 关系，可以解决代码复用的问题。

虽然继承有诸多作用，但继承层次过深、过复杂，也会影响到代码的可维护性。所以，对于是否应该在项目中使用继承，网上有很多争议。

很多人觉得继承是一种反模式，应该尽量少用，甚至不用。为什么会有这样的争议？

02.绘图应用程序案例

2.1 案例的背景

设计一个绘图应用程序，需要有不同形状的类，比如圆形（Circle）、矩形（Rectangle）等，并且这些形状可以有不同的颜色和边框样式。后期还可以会增加其他功能！

2.2 用继承实现多形状

首先定义一个绘图的接口，这个里面我们定义个 draw 绘制方法，如下所示：

abstract class Shape {    public abstract void draw();}

然后实现不同的功能

class Circle extends Shape {    public void draw() {        System.out.println("Drawing a circle");    }}
class Rectangle extends Shape {    public void draw() {        System.out.println("Drawing a rectangle");    }}
class RedCircle extends Circle {    public void draw() {        System.out.println("Drawing a red circle");    }}
class BlueCircle extends Circle {    public void draw() {        System.out.println("Drawing a blue circle");    }}
class RedRectangle extends Rectangle {    public void draw() {        System.out.println("Drawing a red rectangle");    }}
class BlueRectangle extends Rectangle {    public void draw() {        System.out.println("Drawing a blue rectangle");    }}
public class Main {    public static void main(String[] args) {        Shape redCircle = new RedCircle();        redCircle.draw();                Shape blueRectangle = new BlueRectangle();        blueRectangle.draw();    }}

这种设计的问题在于每增加一种新的形状或颜色都需要创建新的子类，类的数量会迅速增长，维护和扩展变得困难。

2.3 用组合实现多形状

通过组合，我们可以更灵活地设计这个系统。我们可以将颜色和形状的概念分离

// 颜色接口interface Color {    void applyColor();}
class RedColor implements Color {    public void applyColor() {        System.out.println("Applying red color");    }}
class BlueColor implements Color {    public void applyColor() {        System.out.println("Applying blue color");    }}
// 形状抽象类abstract class Shape {    protected Color color;
    public Shape(Color color) {        this.color = color;    }
    abstract void draw();}
class Circle extends Shape {    public Circle(Color color) {        super(color);    }
    public void draw() {        System.out.print("Drawing a circle with ");        color.applyColor();    }}
class Rectangle extends Shape {    public Rectangle(Color color) {        super(color);    }
    public void draw() {        System.out.print("Drawing a rectangle with ");        color.applyColor();    }}
public class Main {    public static void main(String[] args) {        Shape redCircle = new Circle(new RedColor());        redCircle.draw();                Shape blueRectangle = new Rectangle(new BlueColor());        blueRectangle.draw();    }}

在这个设计中，我们使用了组合（Composition）而不是继承来实现颜色和形状的结合：

颜色：我们定义了 Color 接口和它的实现类 RedColor 和 BlueColor。

形状：我们定义了 Shape 抽象类，并将 Color 作为一个组合成员。然后，我们创建了具体的形状类 Circle 和 Rectangle。

这样，我们可以任意组合形状和颜色，而不需要创建大量的子类。新增一种颜色或形状只需要创建一个新的实现类，而不需要修改现有的代码。这种设计更加灵活和可扩展，遵循了“组合优于继承”的设计原则。

03.不同鸟类程序案例

3.1 案例的背景

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

3.2 用继承实现多鸟类

我们知道，大部分鸟都会飞，那我们可不可以在 AbstractBird 抽象类中，定义一个 fly() 方法呢？答案是否定的。尽管大部分鸟都会飞，但也有特例，比如鸵鸟就不会飞。鸵鸟继承具有 fly() 方法的父类，那鸵鸟就具有“飞”这样的行为，这显然不符合我们对现实世界中事物的认识。

比如。会不会飞，会不会叫，会不会游泳，这样定义抽象类会比较多。有的可以不用，代码案例

public abstract class AbstractBird {    //...省略其他属性和方法...    public void fly() {        //...    }
    public void eat(){    }
    public void call(){    }
    public void swimming(){    }}public class BirdA extends AbstractBird {    //A ， 不会飞，会叫，会游泳    //...省略其他属性和方法...    public void fly() {        throw new RuntimeException("I can't fly.'");    }
    @Override    public void call() {        super.call();    }
    @Override    public void swimming() {        super.swimming();    }}
public class BirdB extends AbstractBird {    //B， 不会飞，不会叫，会游泳    //...省略其他属性和方法...    public void fly() {        throw new RuntimeException("I can't fly.'");    }
    @Override    public void call() {        throw new RuntimeException("I can't call.'");    }
    @Override    public void swimming() {        super.swimming();    }}
public class BirdC extends AbstractBird {    //C，， 会飞，不会叫，不会游泳    //...省略其他属性和方法...    public void fly() {
    }
    @Override    public void call() {        super.call();    }
    @Override    public void swimming() {        super.swimming();    }}

这种设计思路虽然可以解决问题，但不够优美。因为除了鸵鸟之外，不会飞的鸟还有很多，比如企鹅。这样的设计，一方面，徒增了编码的工作量；另一方面，也违背了最小知识原则（Least Knowledge Principle，也叫最少知识原则或者迪米特法则），暴露不该暴露的接口给外部，增加了类使用过程中被误用的概率。

那再通过 AbstractBird 类派生出两个更加细分的抽象类：会飞的鸟类 AbstractFlyableBird 和不会飞的鸟类 AbstractUnFlyableBird，让麻雀、乌鸦这些会飞的鸟都继承 AbstractFlyableBird，让鸵鸟、企鹅这些不会飞的鸟，都继承 AbstractUnFlyableBird 类，不就可以了吗？继承关系变成了三层。不过，整体上来讲，目前的继承关系还比较简单，层次比较浅，也算是一种可以接受的设计思路。

再继续加点难度。是否会飞？是否会叫？又该如何设计类之间的继承关系呢？两个行为搭配起来会产生四种情况：会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫。如果我们继续沿用刚才的设计思路，那就需要再定义四个抽象类。

3.3 继承的问题暴露

类的继承层次会越来越深、继承关系会越来越复杂。而这种层次很深、很复杂的继承关系，一方面，会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性，必须阅读父类的代码、父类的父类的代码……一直追溯到最顶层父类的代码。

另一方面，这也破坏了类的封装特性，将父类的实现细节暴露给了子类。子类的实现依赖父类的实现，两者高度耦合，一旦父类代码修改，就会影响所有子类的逻辑。

继承最大的问题就在于：继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性。这也是为什么不推荐使用继承。那刚刚例子中继承存在的问题，又该如何来解决呢?

3.4 用组合实现多鸟类

组合相比继承有哪些优势？实际上，可以利用组合（composition）、接口、委托（delegation）三个技术手段，一块儿来解决刚刚继承存在的问题。

前面讲到接口的时候说过，接口表示具有某种行为特性。针对“会飞”这样一个行为特性，我们可以定义一个 Flyable 接口，只让会飞的鸟去实现这个接口。对于会叫、会下蛋这些行为特性，我们可以类似地定义 Tweetable 接口、EggLayable 接口。将这个设计思路翻译成 Java 代码的话，就是下面这个样子：

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() 方法，并且实现逻辑是一样的，这就会导致代码重复的问题。那这个问题又该如何解决呢？

可以针对三个接口再定义三个实现类，它们分别是：实现了 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 关系来替代；多态特性我们可以利用接口来实现；代码复用我们可以通过组合和委托来实现。

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

04.多组合少继承

4.1 组合 VS 继承

如何判断该用组合还是继承？尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。

从上面的例子来看，继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着，我们要定义更多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。

所以，在实际的项目开发中，我们还是要根据具体的情况，来具体选择该用继承还是组合。

4.2 多组合少继承场景

4.3 多组合少继承原因

在面向对象编程中，组合（Composition）和继承（Inheritance）是两种实现代码复用的基本方法。以下是为什么通常建议多用组合而少用继承的一些原因：

灵活性与可扩展性

1. 松耦合：组合通过将一个类的功能委托给另一个类来实现，而不是通过继承。这样，类之间的耦合度较低，修改一个类不会影响另一个类，使系统更灵活。

2. 动态行为改变：组合允许在运行时改变行为，可以通过替换被组合的对象来改变功能，而继承则在编译时决定行为，缺乏灵活性。

代码复用与维护

1. 避免复杂的继承层次：继承层次结构容易变得复杂和难以维护，特别是在多层继承时。而组合则能通过简单的对象组合来实现复杂功能，避免了复杂的继承层次。

2. 增加代码复用：通过组合，可以重用已有的类而不需要创建新的子类，从而减少代码重复，提高代码复用性。

设计原则与模式

1. 遵循“组合优于继承”原则：这是设计模式中的一个重要原则，强调优先使用组合而不是继承来实现代码复用和功能扩展。

2. 符合开闭原则（OCP）：使用组合更容易实现对扩展开放、对修改关闭的原则。新增功能可以通过组合新的类来实现，而不需要修改现有类。

避免继承问题

1. 菱形继承问题：多重继承会导致菱形继承问题，即同一基类被多次继承，导致歧义和复杂性。组合则不存在这个问题，因为它是通过对象的关联来实现的。

2. 基类变更影响：在继承关系中，如果基类发生变化，会影响所有子类。组合则相对独立，修改一个类不会直接影响组合它的类。

组合替代继承的优势在于提供更大的灵活性和代码重用性。通过组合，对象可以动态地关联和组合其他对象，而不是通过继承的静态类层次结构，从而实现更灵活的对象关系和更容易的代码重用。

05.如何选择组合或继承

5.1 如何去选择

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

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

5.2 使用组合方式

前面讲到继承可以实现代码复用。利用继承特性，我们把相同的属性和方法，抽取出来，定义到父类中。子类复用父类中的属性和方法，达到代码复用的目的。

但是，有的时候，从业务含义上，A 类和 B 类并不一定具有继承关系。

比如，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();  }  //..}

5.3 使用继承方式

还有一些特殊的场景要求我们必须使用继承。如果你不能改变一个函数的入参类型，而入参又非接口，为了支持多态，只能采用继承来实现。

比如下面这样一段代码，其中 FeignClient 是一个外部类，我们没有权限去修改这部分代码，但是我们希望能重写这个类在运行时执行的 encode() 函数。这个时候，我们只能采用继承来实现。

public class FeignClient { // feign client框架代码  //...省略其他代码...  public void encode(String url) { //... }} public void demofunction(FeignClient feignClient) {  //...  feignClient.encode(url);  //...} public class CustomizedFeignClient extends FeignClient {  @Override  public void encode(String url) { //...重写encode的实现...}} // 调用FeignClient client = new CustomizedFeignClient();demofunction(client);

尽管有些人说，要杜绝继承，100% 用组合代替继承，但是这里的观点没那么极端！

之所以“多用组合少用继承”这个口号喊得这么响，只是因为，长期以来，过度使用继承。还是那句话，组合并不完美，继承也不是一无是处。只要我们控制好它们的副作用、发挥它们各自的优势，在不同的场合下，恰当地选择使用继承还是组合，这才是我们所追求的境界。

06.多组合少继承总结

• 组合优于继承思考有哪些：组合优于继承，多用组合少用继承。为什么不推荐使用继承？组合相比继承有哪些优势？如何判断该用组合还是继承？

• 为什么说继承有一些争议：继承有诸多作用，但继承层次过深、过复杂，也会影响到代码的可维护性。所以，对于是否应该在项目中使用继承，网上有很多争议。

• 继承的问题暴露有哪些：继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性。

• 组合这种思想有什么问题：继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着，我们要定义更多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。

• 组合替代继承有什么优势：组合替代继承的优势在于提供更大的灵活性和代码重用性，从而实现更灵活的对象关系和更容易的代码重用。