HL🌱数字花园

多组合少继承

8分钟阅读

下面我给你两段工程师视角 + 大白话 + 架构思维的深度讲解，把：

  • 为什么组合优于继承（Composition over Inheritance）

  • 多态是如何支撑依赖注入（DI）的

讲得非常清晰，而且两者之间其实有深刻的联系。

🔥 一、为什么组合优于继承（Composition over Inheritance）

这句话不是口号，而是现代软件工程的核心原则之一。原因非常现实：

🎯 1. 继承耦合太强，组合耦合更低

继承 = “血缘关系”

  • 子类永远绑定父类

  • 父类改一点，子类全崩

  • 继承链越深，越难维护

  • 继承是强耦合

组合 = “搭积木”

  • 你只依赖接口，不依赖具体实现

  • 想换实现？换一个对象就行

  • 组合是弱耦合

大白话：

继承像结婚，组合像合租。合租不合适可以换人，结婚就麻烦了。

🎯 2. 继承限制扩展性，组合更灵活

继承是“白纸黑字写死的”：

  • 一个类只能继承一个父类（Java/Kotlin）

  • 父类设计不好，子类永远受罪

  • 想改变行为必须重写方法，容易破坏父类逻辑

组合则完全不同：

kotlin

class Car(private val engine: Engine)

你可以随时换：

  • GasEngine

  • ElectricEngine

  • MockEngine

  • TurboEngine

组合让行为可以动态替换，继承只能静态绑定。

🎯 3. 继承破坏封装，组合保护封装

继承会暴露父类内部结构：

  • 子类能访问父类 protected 成员

  • 子类必须理解父类内部逻辑

  • 父类内部变化会影响子类

组合不会：

  • Car 不需要知道 Engine 的内部细节

  • Engine 只暴露接口

  • 内部怎么实现无所谓

组合更符合封装原则。

🎯 4. 继承容易导致“继承地狱”，组合不会

继承地狱长这样：

Code

Animal
  └── Mammal
        └── Pet
              └── Dog
                    └── SmartDog
                          └── GuardDog

一旦结构变复杂：

  • 改一个类 → 全链条受影响

  • 逻辑分散在多个父类

  • 调试困难

  • 维护成本爆炸

组合则是：

Code

Dog = AnimalBehavior + GuardBehavior + SmartBehavior

像搭积木一样灵活。

🎯 5. 继承复用“代码”，组合复用“行为”

继承复用的是：

  • 父类的代码

组合复用的是：

  • 对象的行为（接口 + 实现）

现代架构更推崇行为复用，而不是代码复用。

🎯 6. 继承不支持运行时替换，组合支持

继承：

kotlin

val dog = GuardDog()

你不能在运行时把 GuardDog 换成 SmartDog。

组合：

kotlin

dog.behavior = SmartBehavior()

随时换。

🎯 7. 继承违反 SOLID 原则，组合符合

继承容易违反：

  • 开闭原则（OCP）：修改父类影响子类

  • 里氏替换原则（LSP）：子类不一定能替代父类

  • 依赖倒置原则（DIP）：子类依赖父类实现细节

组合天然符合：

  • 依赖接口

  • 行为可替换

  • 扩展不修改原代码

🧠 小结：为什么组合优于继承？

一句话：

继承是强绑定、静态、脆弱的；组合是松耦合、灵活、可扩展的。

🔥 二、多态是如何支撑依赖注入（DI）的？

依赖注入的核心思想是：

依赖接口，而不是依赖具体实现。

而这背后最关键的技术基础就是：多态（Polymorphism）。

🎯 1. DI 的本质：把“实现”替换成“接口”

比如：

kotlin

class Car(private val engine: Engine)

Engine 是接口：

kotlin

interface Engine {
    fun start()
}

DI 容器可以注入任何实现：

  • GasEngine

  • ElectricEngine

  • MockEngine

  • TurboEngine

这就是多态：

父类型引用指向子类型对象。

🎯 2. DI 依赖多态来实现“可替换性”

DI 的核心价值是：

  • 可测试（注入 Mock）

  • 可扩展（注入新实现）

  • 可配置（根据环境注入不同实现）

  • 可维护（不改业务代码）

这些能力都来自多态。

如果没有多态，你只能写：

kotlin

val engine = GasEngine()

那 DI 就没意义了。

🎯 3. DI 容器的工作原理本质就是“多态 + 构造函数注入”

Koin / Spring / Dagger 的流程：

  1. 看到构造函数需要 Engine

  2. 在容器里找到 Engine 的实现

  3. 注入进去

这完全依赖多态：

Engine 类型的参数可以接收任何 Engine 的实现。

🎯 4. 多态让 DI 支持“行为替换”，而不是“代码替换”

继承复用代码，多态复用行为。

DI 需要的正是行为复用：

  • 不关心 Engine 怎么实现

  • 只关心 Engine 能不能 start()

这就是多态的力量。

🎯 5. 多态让 DI 支持“开闭原则（OCP）”

你可以新增一个实现：

kotlin

class SolarEngine : Engine

然后在 DI 容器里注册：

kotlin

single<Engine> { SolarEngine() }

业务代码完全不用改。

这就是 OCP：对扩展开放，对修改关闭。

🧠 小结：多态如何支撑 DI？

一句话：

DI 之所以能“注入不同实现”，完全依赖多态。 没有多态，就没有依赖注入。

🏁 最终总结（你可以直接记住）

✔ 为什么组合优于继承？

  • 继承耦合强、脆弱、难维护

  • 组合灵活、可替换、可扩展

  • 组合符合 SOLID 原则

  • 组合是现代架构（DI、Clean Architecture）的基础

✔ 多态如何支撑依赖注入？

  • DI 依赖接口，而接口依赖多态

  • 多态让 DI 可以注入不同实现

  • 多态让 DI 支持测试、扩展、替换

  • 多态让 DI 实现开闭原则

如果你愿意，我还能继续帮你：

🔥 画一张“继承 vs 组合 vs 多态 vs DI”的关系图 🔥 讲讲“组合 + 多态 + DI 如何构成现代架构的三大支柱” 🔥 讲讲“为什么 Android 官方架构（Hilt + MVVM）完全基于组合和多态”

你想继续深入哪一块？

关系图谱