面向对象高级设计：多态、组合与SOLID的工程实践

上周做代码评审时，我看到一个印象很深的实现：业务方把“用户”设计成基类，“管理员”继承“用户”，“超级管理员”又继承“管理员”。三层继承下来，一次最简单的资料修改需求，改了两次父类，检查了五个子类，最后还差点把权限逻辑改崩。同事很委屈：面向对象的三大特性我全用了啊，继承、封装、多态，一个没落下，为什么还是被点名？

这个场景我见得太多次了。问题不在语法，而在设计。会用 class 只是拿到了面向对象的入场券，真正拉开水平差距的，是面对具体业务时，你选择用哪种方式组织类、定义边界、处理变化。这也是我理解“面向对象高级”这四个字的核心：高级不是把继承用得更复杂，而是懂得在合适的时候不继承。

这篇文章我打算跳出单语言视角，把 Java、C++、Python 三套主流实现摆在一起对比：多态底层的虚表机制、接口与抽象类的边界、组合与继承的取舍、SOLID 在工程里的实际落地，以及我在三种语言里分别踩过的高级坑。既适合想把面向对象理解得更通透的初学者，也适合写了几年代码但总觉得设计力不够的同学。

1. “高级”不是语法堆砌：从会用类到设计类

1.1 一个典型的“会写类但不高级”的代码

以订单折扣为例。假设现在有三种用户：普通用户、VIP、超级VIP，对应折扣从无到九折再到八折。最常见的写法是这样的：

python复制class Discount:
    def calc(self, amount):
        return amount


class VIPDiscount(Discount):
    def calc(self, amount):
        return amount * 0.9


class SuperVIPDiscount(VIPDiscount):
    def calc(self, amount):
        return amount * 0.8

先说结论：这段代码能跑，而且单看每个类都写得“没毛病”——继承用得工整，方法覆盖也正确。但放到真实业务里，它很快就会变成维护的噩梦。

第一个问题：如果运营某天说要加一个“周末限时八折”呢？你需要在继承树上再加一层吗？假如一个用户既是超级VIP，又赶上周五促销，那他的折扣应该是 0.8 乘以 0.8 等于 0.64，还是只取最低折扣 0.8？这个组合逻辑用继承树根本表达不清楚，只能硬编码，要么在调用处花式写 if，要么在子类里复制粘贴。

第二个问题是耦合。SuperVIPDiscount 继承 VIPDiscount，意味着父类里任何方法改动都直接影响子类，而父类和子类在语义上并不天然是“是一种”关系——超级VIP并不是 VIP 的一种子类型，它只是“VIP + 额外权益”的组合。用继承去表达这种叠加关系，本质上是在用错误的抽象建模。

这就是典型的“语法很熟，设计不够”。class、protected、override 这几个关键字的用法全对，但类与类之间的关系选错了。面向对象的高级感，恰恰体现在这个关系选择上。

1.2 三大语言，同一个需求，三种设计哲学

同一个需求：折扣可能叠加，未来还会加新规则。三种语言的处理方式差异很明显。

Java 的做法是先定义接口，然后让每个策略实现接口，再用组合把策略传进去。这里面有一种“先定契约，再写实现”的秩序感。

java复制public interface Discount {
    double calc(double amount);
}

public class VipDiscount implements Discount {
    private double rate;
    public VipDiscount(double rate) { this.rate = rate; }
    @Override public double calc(double amount) { return amount * rate; }
}

C++ 的设计思路类似，但没有专门的 interface 关键字，通常用纯虚类来表达抽象，运行时用虚函数分派。好处是性能可控，坏处是内存管理要自己操心。

Python 则完全走了另一条路。它更倾向“约定优于定义”：只要一个对象有 calc 方法，并且行为符合预期，它就是折扣策略。所以 Python 里你甚至可以不继承任何东西，直接写一个普通函数传进去。这种灵活让新手觉得方便，但也会让项目变大后缺乏边界感。

这三种语言的设计哲学没有绝对优劣，只是出发点不同。我把它们的差异整理成一张表：