面向对象三大特性：封装、继承与多态的真实工程实践

面向对象三大特性——封装、继承、多态，大概是程序员简历上出现频率最高的几个字，同时也是被误解得最狠的几个词。我面试过不少候选人，几乎人人都会背“封装隐藏细节，继承实现复用，多态让同一接口呈现不同行为”，可一聊到具体项目就发现不对味儿：有人以为字段加private再写一堆getter/setter就是封装，有人为了让两个类共享方法强行搞出八层继承，还有人天天把多态挂嘴边，写的代码里却全是if-else。

这篇文章我不想再给你背一遍教科书定义，而是想把我这些年写代码、做代码评审、修线上Bug时对这三个特性的真实理解和盘托出。适合谁看？我觉得三类人最合适：刚学完语法但写不出好代码的学生，工作一两年想系统梳理的初级开发，以及要带团队、做设计评审、想跟新人把这事儿说清楚的技术负责人。看完你至少能明白一件事：这三个词不是八股文考点，而是三个能实实在在帮你少加班、少改Bug的设计武器。

另外提醒一下，搜“封装”很容易搜到一堆硬件领域的术语，比如BGA封装、0603封装尺寸、AD封装库，如果你是为了查芯片封装才点进来的，那可能跑错片场了。本文只讨论程序设计里的面向对象。

1. 三大特性到底在解决什么问题：一个从面条代码到分层设计的故事

1.1 没有封装、继承、多态的世界是什么样子

想象一个没有面向对象的系统长什么样。你可能有一个巨大的类，里面塞满了方法，或者干脆是一堆互相调用的函数，没有任何边界。所有数据直接暴露，A模块可以随手改掉B模块的字段，C函数需要复制D函数的一大段逻辑，想加一个新功能，先得搞清楚从哪儿下手，改完之后又担心把其他地方带崩了。

我早年接手过一个物流订单处理系统，就是这种“面条代码”的典型。一个订单处理Service类有三千多行，里面几十个字段全是public，各种方法互相调用，没有层次、没有边界。加一个“订单取消”功能，我光是找应该改哪里就花了两天，改了之后还出了线上事故——因为我改了一个字段的含义，另一个模块的统计逻辑直接算错了。那次事故之后我彻底想明白一个事：软件复杂度不是靠纪律约束就能管住的，必须在代码结构层面强制划出边界和层次。

1.2 三大特性分别解决了哪三个核心矛盾

现在我们可以把三大特性对号入座了。

封装解决的是复杂度治理的问题。一个软件系统一旦变大，各个模块之间就会互相牵扯。封装的核心思路是：每个类把自己的内部状态和实现细节锁起来，对外只暴露稳定的、有明确语义的接口。别人只能用你允许的方式操作你的对象，你的内部怎么变，那是你自己的事。说直白点，封装划出了一条“管好你自己”的边界线。

继承解决的是类型关系表达与代码复用的问题。两个类之间有“is-a”的关系——猫是一种动物，圆是一种形状，那么可以把公共的属性和行为放到父类里，子类继承后自动拥有，还可以按需覆写或扩展。它让代码有了层次感，公共逻辑不至于散落在各个子类里重复出现。

多态解决的是调用方与实现方的解耦问题。调用方只需要面向一个抽象类型编程，运行时编译器再帮你决定具体执行哪个实现。有了多态，你才能写出“对扩展开放、对修改关闭”的代码：新增一种实现时，不需要改动调用方的逻辑。

这三个特性不是孤立的。封装是基础，继承和多态在封装之上展开。一个好的面向对象设计，通常是先用封装划定边界，再用继承表达类之间的稳定关系，最后用多态让系统具备扩展的弹性。后面我用一个支付系统的完整案例把三者串起来讲，这里先不展开。

2. 封装：边界感才是第一关键词，private只是表面功夫

2.1 最大的误区：把字段私有化再加getter/setter就叫封装

很多初学者或者工作一两年的开发，对封装的理解停留在“private + getter/setter”。我之前在一个项目里看到过这样的代码：

java复制public class User {
    private String name;
    private int age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

这段代码编译没问题，但它不是封装，只是一个裸数据容器。为什么？因为name和age这两个字段的定义完全暴露给了外部，外部想设什么就设什么，想取什么就取什么，没有受到任何业务规则的约束。真正的封装，保护的是业务不变量。比如年龄不能为负数，邮箱必须符合格式，账户余额不能随意变成负数——这些规则应该被封装在类的内部，让外部代码根本没办法触碰到非法状态。

2.2 一个教科书级的封装：让不变量“根本不可能被破坏”

我举一个经典的银行账户例子，你对比一下就懂了：

java复制public class BankAccount {
    private double balance;

    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("存款金额必须大于0");
        }
        this.balance += amount;
    }

    public void withdraw(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("取款金额必须大于0");
        }
        if (amount > this.balance) {
            throw new IllegalStateException("余额不足");
        }
        this.balance -= amount;
    }

    public double getBalance() {
        return this.balance;
    }
}

这个类外部只能通过deposit和withdraw来改变balance，而这两个方法内部实现了业务规则校验，所以“余额不能为负”这个不变量从机制上就得到了保障。注意这里连setBalance都没有，因为余额根本不应该被外部直接设置。这才是封装的本意：把不变量锁在类内部，让外部代码没有能力破坏它。

封装还有一个附带好处，你内部实现怎么改，都不会影响调用方。比如将来要把balance从double改成BigDecimal来避免精度问题，只要方法签名不变，所有调用方的代码都不用动。这就是“接口稳定、实现自由”的价值。

2.3 实战案例：一个请求库/拦截器的封装设计

封装不只是“类”级别的概念，往上可以到模块、包、组件。我拿热词里反复出现的“请求封装”来举个例子。很多团队做前端或客户端开发时，会封装一个统一的HTTP请求层，把超时设置、Token刷新、错误码统一转换、日志上报全部收敛在一个地方，对外只暴露业务接口：

javascript复制export function createRequestAdapter(config) {
  const baseURL = config.baseURL;
  const timeout = config.timeout || 8000;

  async function request(path, options) {
    // 这里统一处理超时、重试、Token 刷新、错误码映射等逻辑
    // 调用方完全不需要关心这些细节
    const response = await fetch(`${baseURL}${path}`, {
      ...options,
      headers: buildHeaders(options.headers),
    });
    if (response.status === 401) {
      await refreshToken();
      return request(path, options); // 一次重试
    }
    return parseResponse(response);
  }

  return {
    get: (path, params) => request(path, { method: 'GET', params }),
    post: (path, data) => request(path, { method: 'POST', body: JSON.stringify(data) }),
  };
}

这样做的好处，调用方拿到的是一组非常稳定的业务方法get、post，底层是fetch还是axios，要不要做重试，Token怎么刷新，统统被隔离在封装内部。将来就算把fetch换成axios，或者调整超时策略，所有业务页面一行代码都不用改。这就是封装在模块层面的作用——把“会变的东西”和“稳定不变的东西”剥离开。

我在实际项目中见过反面的写法：每个页面各自写一套请求逻辑，有的忘了带Token，有的没做超时，有的错误提示弹得乱七八糟。等到要统一接入新的埋点系统时，得全局搜代码逐个改，眼看着二十多个文件来回翻。这个教训告诉我们，封装不是“代码写得规范”这种软要求，而是工程成本控制上的硬需求。

2.4 C++的pimpl惯用法：把封装做到编译级

封装在C++里有个很有意思的经典实践，叫pimpl（Pointer to Implementation，指向实现的指针），也是热词里提到的“Qt使用pimpl模式进行封装”。核心思路是：头文件里只放一个不透明指针，所有真实实现全部挪到实现文件里。

cpp复制// widget.h
class WidgetImpl;

class Widget {
public:
    Widget();
    ~Widget();
    void setEnabled(bool enabled);

private:
    WidgetImpl* impl_;
};

cpp复制// widget.cpp
#include "widget.h"

class WidgetImpl {
public:
    void setEnabled(bool enabled) {
        // 真实的业务逻辑
    }
};

Widget::Widget() : impl_(new WidgetImpl()) {}
Widget::~Widget() { delete impl_; }

void Widget::setEnabled(bool enabled) {
    impl_->setEnabled(enabled);
}

这样做的好处有三个：第一，头文件不再暴露私有成员的具体实现，外部依赖这个头文件时不需要看到一堆内部数据结构；第二，改实现文件里的东西，所有包含widget.h的源文件都不需要重新编译，编译时间大幅缩短；第三，实现细节被物理性隐藏，外部代码想偷偷访问内部状态都无从下手。这是C++世界里“接口与实现分离”最极致的体现。

3. 继承：复用是副产物，is-a关系才是唯一使用理由

3.1 用错得最狠的两种继承姿势

我在代码评审里见过太多把继承当“代码复制工具”的例子。最常见的一种是“为了复用方法而继承”——A类里有个方法，B类也想用，于是让B继承A，结果B和A在业务上八竿子打不着。比如让一个Order类继承User类，就因为Order里要显示用户名。这种继承会把业务上毫无关系的两个类强行绑定在一起，等到User类内部逻辑一变，Order类莫名其妙跟着出Bug，排查起来哭都来不及。

第二种常见错误是“继承层级过深”。我接过一个项目，一个DAO体系有六层继承：GrandBaseDao -> BaseDao -> AbstractUserDao -> UserDaoImpl -> SpecificUserDao，每层各加几个方法，加起来几千行。最后的结果是，任何一个父类的方法改动都可能引发连锁反应，新来的同事根本不敢碰这坨代码。后来我用一个简单的规则去说服团队重构：每一层继承必须有明确、独立、成立的is-a理由，否则就拆出来用组合。 这一拆，直接从六层砍到两层。

3.2 继承的正确打开方式：抽象基类 + 模板方法

那什么时候可以放心用继承？我的经验是：当你有一个稳定的算法骨架，但其中某些步骤需要子类填充时，继承就特别合适。这就是“模板方法模式”。

比如一个报表生成器，生成报表的流程是固定的：采集数据 -> 渲染数据 -> 输出格式化。但不同的报表，采集和渲染的方式完全不同。这时可以设计一个抽象基类：

java复制public abstract class ReportGenerator {
    public final String generate() {
        String data = collectData();
        String rendered = render(data);
        return formatOutput(rendered);
    }

    protected abstract String collectData();

    protected abstract String render(String data);

    protected String formatOutput(String content) {
        return content;
    }
}

然后让不同的报表类继承它，分别实现collectData和render。generate是整个算法骨架，用final锁住不允许子类改写，子类只需要关心自己负责的那两个步骤。这才是继承的正确初衷：父类定义“怎么做这件事的整体流程”，子类填充“每个步骤里具体怎么做”。这比单纯为了复用几个方法而硬凑继承，要合理得多。

3.3 不同语言的继承机制差异：别被一门语言的规则误导

很多新手在Java里学的“单继承”，到了C++被多继承、菱形继承吓一跳，到了Python又发现MRO（方法解析顺序）的概念。同样叫“继承”，各语言的处理方式差别很大，用之前一定要搞清楚你手头这门语言的规则。

C++支持多继承，如果两个父类有同名成员，子类使用该成员时会产歧义，必须显式指定。更麻烦的是菱形继承问题：A派生B和C，B和C再共同派生D，D里会包含两份A的成员。解决办法是用virtual继承：

cpp复制class A { public: int x; };
class B : virtual public A {};
class C : virtual public A {};
class D : public B, public C {};

加了virtual之后，D里就只有一份A的成员了，省去了二义性的麻烦，但代价是运行时性能略降，代码可读性也更差。这也是为什么很多C++项目规范里直接禁止多继承，只用单继承加接口。

Python的继承靠MRO线性化来解析方法。比如经典的菱形继承，如果中间层都正确调用了super()，Python会自动按C3线性化的顺序找到正确的下一个方法。这里不展开MRO的全部细节，只想提醒一点：在Python里做多继承，如果一个类的方法解析顺序和你预想的不一样，先确认一下继承时MRO的顺序。这个坑我踩过不止一次，后来养成了一个习惯，凡是多继承必定先打印类的__mro__确认顺序，再动手写逻辑。

Java则是单继承配合接口多实现，这其实是相对最“省心”的一种设计：类的继承层次简单，接口提供行为契约。当年设计Java语言的人把多继承砍掉，现在看来反而帮助Java社区避免了很多C++开发里的继承混乱问题。

3.4 一个判断标准：如果子类覆写后要抛异常，那继承就错了

我总结了一套很管用的“继承味道检测法”，分享给大家。如果你发现某个子类在覆写父类方法的时候，需要抛UnsupportedOperationException或者直接空实现，那大概率说明“is-a”关系是伪造的。比如让鸟继承动物父类，但企鹅不会飞，于是sparrow覆写fly方法时抛异常——正确的做法应该是把fly能力拆成接口Flyable，只有会飞的鸟去实现它，而不是在父类强行安排一个会被“打脸”的方法。

类似的情况还包括：子类为了避开父类的某些状态而把方法置空；调用方为了使用子类功能不得不强行做类型判断。这些坏味道一旦出现，就说明该用组合了。组合的本质是“has-a”关系：一个类持有另一个类的引用，通过委托复用功能，彼此之间没有强绑定。大多数场景下，组合比继承更灵活、更安全。

4. 多态：从虚函数表到鸭子类型，搞懂动态分派的真面目

4.1 运行时多态的底层机制：一张虚函数表搞定动态分派

多态的实现机制，以C++为例，就是虚函数表（vtable）。每一个含有虚函数的类，在编译期会生成一张虚函数表，表里存放的是这个类的虚函数入口地址。每个对象里有一个隐藏的虚指针（vptr）指向这个表。当调用虚函数时，程序先通过vptr找到表，再从表中取出对应函数地址，然后调用。

代码写出来是这样的：

cpp复制class Shape {
public:
    virtual double area() const = 0;
    virtual ~Shape() = default;
};

class Circle : public Shape {
public:
    Circle(double r) : r_(r) {}
    double area() const override { return 3.1415926 * r_ * r_; }
private:
    double r_;
};

class Rectangle : public Shape {
public:
    Rectangle(double w, double h) : w_(w), h_(h) {}
    double area() const override { return w_ * h_; }
private:
    double w_, h_;
};

double totalArea(const std::vector<Shape*>& shapes) {
    double total = 0;
    for (const auto* s : shapes) {
        total += s->area();
    }
    return total;
}

你在调用s->area()的时候，编译器和运行时的配合是这样的：编译器知道area是虚函数，于是生成一段代码——顺着s的vptr找到虚函数表，再找到Circle或Rectangle的area地址，跳过去执行。具体执行哪个实现，在运行期才确定，这就叫动态分派。

Java的实现思路也类似：每个对象都关联自己的类元数据，方法调用时通过虚方法表解析。Python的鸭子类型更直接——不需要继承关系，调用方只关心对象“有没有这个方法”，运行时不检查类型，直接找属性，找不到就抛AttributeError。这三种差异决定了你在不同语言里使用多态的思维模式也不一样：C++和Java要求你提前整理好类型层级，Python则可以更随性，但随性带来的代价是运行时才能发现方法缺失。

4.2 编译时多态：重载、模板与C语言的宏多态

很多人以为多态只能发生在运行时，这是个误会。多态的本质是“同一段逻辑能作用于多种类型”，只不过有的在运行时体现，有的在编译期就已经完成了。

C++的函数重载和运算符重载是编译时多态。编译器根据实参类型，在编译期决定调用哪个重载版本。C++模板则是更强大的编译时多态：

cpp复制template <typename T>
T add(T a, T b) {
    return a + b;
}

int i = add(1, 2);
double d = add(1.0, 2.5);

编译器会为这两种调用各生成一份适配版本的代码。好处是零运行时开销、类型安全，坏处是编译时间变长、生成的代码体积变大、报错信息特别难读。

C语言没有类和虚函数，但也有自己的“宏多态”玩法：

c复制#define ADD(a, b) ((a) + (b))

int i = ADD(1, 2);
double d = ADD(1.0, 2.5);

这是最粗粒度的多态：宏在预处理阶段按文本展开，跟类型无关。但宏没有类型检查，安全性极差，在大型项目里滥用宏会导致代码难以调试。所以在C语言里，很多成熟项目会克制使用宏，把它限制在少量确定需要通用操作的场景。

说到Java泛型，那也是一种编译时多态，但它和C++模板有个重要区别：Java泛型在运行时会被擦除，编译器插入强转检查。所以在Java里不能像C++那样用泛型做new T()这种操作，这是一个很典型的语言机制差异。搞清楚这些差异，你在跨语言开发时才不会踩坑。

4.3 多态的真正价值：面向抽象编程，而不是面向具体类编程

多态最大价值，不是让你少写几个if-else，而是让“调用方”和“实现方”彻底解耦。调用方只需要依赖抽象接口，具体实现可以随意替换，这是依赖倒置原则的具体体现。

比如说，一个报警通知模块：

java复制public interface Notifier {
    void notify(String message);
}

public class EmailNotifier implements Notifier {
    public void notify(String message) { /* 发邮件 */ }
}

public class SmsNotifier implements Notifier {
    public void notify(String message) { /* 发短信 */ }
}

public class AlertService {
    private final Notifier notifier;

    public AlertService(Notifier notifier) {
        this.notifier = notifier; // 具体实现通过构造注入
    }

    public void alert(String message) {
        notifier.notify(message);
    }
}

AlertService只依赖Notifier这个抽象，它根本不关心发的是邮件还是短信。将来新增一个钉钉通知，只需要加一个DingTalkNotifier实现Notifier，然后把它注进去，AlertService一行代码都不用改。这就是所谓的“对扩展开放，对修改关闭”。要是在没有多态的情况下，每次新增通知渠道，AlertService里就得加一个if-else分支，改着改着，类就膨胀成了一个谁也碰不得的大泥球。

5. 一个支付系统设计案例：三大特性是如何协同工作的

5.1 业务模型设计：封装领域核心，继承抽象基类，多态支撑扩展

前面讲了概念，这一节用大家最常接触的支付系统，把封装、继承、多态怎么协同工作完整梳理一遍。

首先定义支付处理器抽象基类。所有支付渠道都要走一套相同流程：校验请求、调渠道接口、处理结果、失败补偿、通知结果。这个流程是稳定的算法骨架，可以写在抽象基类里，用模板方法固定下来：

java复制public abstract class PaymentHandler {
    public final PaymentResult handle(PaymentRequest request) {
        validate(request);
        PaymentResult result = doPay(request);
        if (result.isSuccess()) {
            notifySuccess(request, result);
        } else {
            compensate(request, result);
        }
        return result;
    }

    protected abstract void validate(PaymentRequest request);

    protected abstract PaymentResult doPay(PaymentRequest request);

    protected void notifySuccess(PaymentRequest request, PaymentResult result) {
        // 默认发送消息通知，子类可选覆写
    }

    protected void compensate(PaymentRequest request, PaymentResult result) {
        // 默认补偿逻辑，比如记录日志、触发对账
    }
}

然后让不同渠道继承这个基类：

java复制public class AlipayHandler extends PaymentHandler {
    protected void validate(PaymentRequest request) {
        // 支付宝特有的参数校验
    }

    protected PaymentResult doPay(PaymentRequest request) {
        // 调支付宝开放平台接口
    }
}

public class WechatPayHandler extends PaymentHandler {
    protected void validate(PaymentRequest request) {
        // 微信支付特有的校验
    }

    protected PaymentResult doPay(PaymentRequest request) {
        // 调微信支付接口
    }
}

这里用到的是继承：算法骨架写在父类，渠道差异通过覆写子类来实现。接下来是多态：调用方手里只持有PaymentHandler这个抽象类型，运行时由工厂或者注册表决定注入哪一份实现：

java复制public class PaymentFacade {
    private final Map<PayChannel, PaymentHandler> handlers;

    public PaymentFacade(List<PaymentHandler> handlerList) {
        this.handlers = handlerList.stream()
                .collect(Collectors.toMap(PaymentHandler::channel, h -> h));
    }

    public PaymentResult pay(PaymentRequest request) {
        PaymentHandler handler = handlers.get(request.channel());
        if (handler == null) {
            throw new UnsupportedOperationException("不支持的支付渠道");
        }
        return handler.handle(request);
    }
}

最后，PaymentFacade就是对外的一层封装：外部调用方只需要知道pay这个方法，传入一个请求，得到结果。至于底层是支付宝还是微信、每个渠道的对接细节、失败后怎么补偿，全被封装和隐藏起来了。

这个设计里，封装、继承、多态各司其职。封装负责控制复杂度，把渠道差异、补偿逻辑、回调通知都收敛在内部；继承让所有渠道复用稳定的流程骨架；多态让新增支付渠道时只加一个Handler类，调用方零改动。这是一个典型的、可以直接抄作业的可扩展设计。

5.2 用SOLID原则检查这个设计

拿SOLID原则逐条检查这个支付系统设计，你会发现它是站得住脚的。

开闭原则：新增支付渠道不需要改已有代码，只要新增一个类并注册进去，系统就对扩展开放、对修改关闭。里氏替换原则：所有子类都严格遵循抽象基类的方法契约，AlipayHandler和WechatPayHandler可以随时替换父类PaymentHandler的位置，不会破坏调用方逻辑。单一职责原则：每个Handler只负责一个渠道的对接，PaymentFacade只负责分发请求，各司其职。接口隔离原则：PaymentHandler这个抽象类的粒度也刚刚好，没有强行塞入某个渠道特有的方法。依赖倒置原则：上层PaymentFacade依赖的是抽象PaymentHandler，而不是某个具体的渠道实现类。

这套检查和验证方法，我现在每做一个新模块设计都会在脑子里过一遍。你准备设计自己的系统时，也可以把SOLID当一面镜子：如果哪个原则被违背了，说明设计里大概率藏着将来会爆雷的点。

6. 实战项目里的经典坏味道与排查思路

6.1 继承层级过深的代码坏味道与重构

上面说到的那个六层DAO继承问题，我展开讲讲排查和重构过程。

当时现象是：业务方提了一个需求，要给某个查询加一个过滤逻辑。我沿着调用链往上追，发现查询方法在UserDaoImpl里，而它依赖了父类AbstractUserDao里的一个公共方法，还要通过BaseDao里的连接池，再往上还有GrandBaseDao的通用查询模板。一次普通的SQL改造，牵动了三层父类的方法签名。更离谱的是，因为GrandBaseDao的一个方法注解改动，所有子类都受影响，线上出现了偶发性的连接不释放。

排查思路是这样的：第一步，把所有继承关系用一张关系图画出来，逐个节点问自己“这个类的存在理由是不是is-a”。第二步，发现中间两层全是所谓“公共工具沉淀”，根本不是业务实体的is-a关系。第三步，把这些公共方法抽到一个独立的QuerySupport工具类里，用组合方式注入到需要的DAO中，把硬绑定的继承链拆成软绑定的依赖关系。第四步，从顶层接口到底层实现，重新梳理每一层职责，最终从六层砍到两层：接口 + 实现类。

这次重构让我深刻体会到：继承一旦被当成“代码复用工具箱”，你就看不到它带来的耦合膨胀，等到线上问题集中爆发，处理成本已经是几何级数增长。

6.2 多态滥用：注册表里塞了三千个Handler

多态虽好，但也不是越多越好。有一回我在另一个项目里看到，一个事件分发系统在启动时注册了三千多个Handler，每个Handler只处理一个事件类型。听上去很符合开闭原则对吧？但问题是，这些Handler分散在三十多个子模块里，每个子模块都往一个静态注册表里塞自己的实例。

到了排查线上问题的时候，我们发现有一个事件始终没有被正确消费。要查这个事件注册在哪，得全局IDE搜索Handler类名，然后一个个看注册代码。后来一查才发现，有编号为1到3000的事件，创立时是“每个事件一个Handler”的完美设计，但维护了两年之后，注册顺序、事件编号、优先级全都变得混乱不堪，光靠文档根本记不住。

这个案例给我的教训是：多态是手段，不是目的。当你发现“每个实现类只有一个方法、只服务一个场景”时，大部分情况下说明抽象粒度做得太小了，应该用分组注册、事件转发、配置映射等方式把数量降下来。合理的设计应该让人一眼能看出系统有哪些业务域、每个域下面有哪些实现，而不是靠三千个类去描述一个简单系统。

6.3 构造函数里调虚函数：一个C++经典坑

另一个特别典型的坑，是C++构造函数里调用虚函数。很多人以为在构造函数里调用虚函数会触发多态，其实不会。原因是，在基类构造函数执行的时候，派生类还没构造完成，虚函数表指针指向的是基类的vtable，所以虚函数调用会解析到基类版本。

cpp复制class Base {
public:
    Base() { print(); }
    virtual void print() {
        std::cout << "Base" << std::endl;
    }
};

class Derived : public Base {
public:
    Derived() : Base() { print(); }
    void print() override {
        std::cout << "Derived" << std::endl;
    }
};

// 构造 Derived 对象，输出结果是：
// Base
// Derived

如果有人在Base的构造函数里调用print，期望触发Derived的逻辑，就会踩坑。正确做法是：构造函数里只做与当前类相关的初始化，别调用任何虚函数；如果需要初始化时执行一些“看似多态”的逻辑，可以定义纯虚函数，再要求子类通过某种初始化方法显式调用来完成。

6.4 封装被框架机制击穿：实体类里塞满了setter

最后一类我特别想说的坏味道，是封装被各种框架的强制要求给“击穿”了。Java里最典型的就是配合MyBatis、Jackson这些框架，实体类不得不暴露一堆getter和setter，结果业务规则的封装形同虚设，谁都能往里塞数据。

这不是框架的错，是你的分层没有做好。推荐的做法是：持久层实体、传输层DTO、领域模型分开。数据库映射用的实体类，可以保持“贫血”状态，允许框架直接读写字段；但核心业务逻辑一定要放在有自己的业务方法、能维护不变量、不对外疯狂暴露setter的领域模型里。DTO负责跨层传输，VO负责视图展示，各司其职。核心的一句话是：为了框架方便，把业务的封装丢掉了，那就等于自己放弃了面向对象最大的好处。

顺带说一句，Python和JavaScript里因为动态语言的特性，封装要靠“惯例”来维系，比如Python的_前缀表示“别碰我”。但惯例这东西，总有人不遵守，所以在团队里最好用代码规范工具强制检查，别指望每个人都自觉。

写代码这些年，我对封装、继承、多态的理解经历了几个阶段：语言课上学语法，项目里照葫芦画瓢，直到线上出过几次大事才开始反思这些基础概念到底在帮我抵御什么。现在我给自己定了一个习惯，每次设计新类之前先问三个问题：这个类的边界在哪里？它和别的类型到底是什么关系？调用方期望它表现成什么样？这三个问题正好对应封装、继承、多态——边界感清晰、关系表达准确、面向抽象编程。如果你写代码时也能养成这样的自问习惯，这三个特性就不再是简历上的几个字，而是你面对复杂业务时真正顺手的工具。