开闭原则（OCP）上：定义与核心思想

各位同学，今天我们来聊一个在面向对象设计中地位极高的原则——开闭原则。英文全称是 Open-Closed Principle，简称 OCP。

说实话，我刚开始接触这个原则时，觉得它有点「反直觉」。什么叫对扩展开放，对修改关闭？代码不让改，那还怎么干活？

后来在真实项目中摔过几次跟头，才慢慢品出其中的味道。嗯，今天我就把这几年的体会，掰开了揉碎了讲给你听。

一、开闭原则的定义

开闭原则最早由 Bertrand Meyer 在 1988 年提出。它的核心定义只有一句话：

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

说白了就是：当需求变化时，尽量通过增加新代码来实现，而不是修改已有的代码。

你想想看，一个系统如果每次加功能都要改老代码，那改着改着就改崩了。我见过太多项目，就是因为老代码被反复修改，最后变得像一团乱麻，谁都不敢动。

二、为什么需要开闭原则？

我举个例子。假设你写了一个图形绘制系统，最开始只支持画圆形：

class GraphicEditor {
public:
    void drawCircle(const Circle& c) {
        // 画圆的逻辑
        std::cout << "绘制圆形" << std::endl;
    }
};

后来需求来了，要支持画矩形。你怎么办？

最直接的做法——在 GraphicEditor 里加一个 drawRectangle 方法。这看起来没什么问题，对吧？

但你再想想，如果后面还要支持三角形、五边形、六边形……每次加一个新形状，你都要修改 GraphicEditor 类。这个类会变得越来越臃肿，而且每次修改都可能引入 bug。

我曾经在一个项目中接手过类似的代码。那个 GraphicEditor 有 2000 多行，里面塞了十几种图形的绘制方法。每次加新图形，都要在好几个地方同步修改。有一次同事改漏了一个地方，结果程序跑起来直接崩溃。嗯，那场面，真是惨不忍睹。

三、核心思想：抽象化是关键

开闭原则的核心武器是什么？抽象化。

怎么理解？我们来看改进后的设计：

// 定义一个抽象基类
class Shape {
public:
    virtual void draw() const = 0;
    virtual ~Shape() = default;
};

// 具体形状继承抽象类
class Circle : public Shape {
public:
    void draw() const override {
        std::cout << "绘制圆形" << std::endl;
    }
};

class Rectangle : public Shape {
public:
    void draw() const override {
        std::cout << "绘制矩形" << std::endl;
    }
};

// 编辑器只依赖抽象
class GraphicEditor {
public:
    void drawShape(const Shape& shape) {
        shape.draw();  // 多态调用
    }
};

看到区别了吗？GraphicEditor 不再依赖具体形状，而是依赖 Shape 这个抽象接口。

现在要加新形状，比如三角形：

class Triangle : public Shape {
public:
    void draw() const override {
        std::cout << "绘制三角形" << std::endl;
    }
};

GraphicEditor 一行代码都不用改。这就是「对修改关闭」。而通过继承 Shape 添加新类，这就是「对扩展开放」。

关键点：抽象化让系统的核心部分稳定不变，变化的部分通过扩展来吸收。这就像给系统装了一个「扩展接口」，新功能插上去就能用，不用拆机器。

四、开闭原则的层次结构

为了让你更直观地理解，我画了一张图：

开闭原则核心结构 Shape（抽象基类） Circle Rectangle Triangle（新增） GraphicEditor 对扩展开放（新增类） · 对修改关闭（不修改编辑器）

从图中可以清楚看到：抽象层（Shape）是稳定的核心，具体实现（Circle、Rectangle、Triangle）可以不断扩展，而依赖抽象的客户端（GraphicEditor）不需要任何修改。

五、开闭原则的收益

遵循开闭原则能带来哪些实实在在的好处？我总结了几点：

收益 说明
降低修改风险 已有代码不修改，就不会引入新 bug。我在项目中深有体会——改一行老代码，可能牵出三个隐藏问题。
提高可维护性 新功能以独立模块的形式添加，不影响原有结构。代码像搭积木一样清晰。
增强复用性 抽象接口可以被多个客户端复用。比如 Shape 接口，不仅 GraphicEditor 能用，其他模块也能用。
便于团队协作 不同开发者可以同时开发不同的扩展模块，互不干扰。你写你的三角形，我写我的矩形，最后插上去就行。

六、常见误区与避坑指南

讲到这里，我得提醒你几个容易踩的坑。

误区一：过度抽象

有些人一听到「抽象化」，就把所有东西都抽象一遍。结果搞出一堆接口和基类，代码变得极其复杂。我曾经见过一个项目，一个只有三个方法的类，硬是抽象出了两层接口。最后连作者自己都搞不清该继承哪个。

正确做法：只在确实需要扩展的地方使用抽象。不要为了抽象而抽象。

误区二：认为开闭原则意味着「完全不修改」

这是误解。开闭原则说的是「对修改关闭」，指的是已经稳定、经过测试的核心模块不要轻易修改。但如果是设计阶段，或者模块本身就不稳定，该改还是要改。

正确做法：先让系统跑起来，再逐步识别哪些部分是稳定的，然后对它们应用开闭原则。

我的一个小建议：刚开始练习时，可以先用「如果加一个新功能，我需要改哪些文件」来检验设计。如果需要改的文件越少，说明开闭原则贯彻得越好。理想情况下，只需要新增一个文件，其他文件都不用动。

七、开闭原则与多态的关系

你可能已经注意到了，开闭原则的实现离不开多态。C++ 中的虚函数、继承、接口，都是实现开闭原则的技术手段。

但我要强调一点：多态只是工具，开闭原则才是目标。不要为了用多态而用多态，要时刻问自己：这个设计是否让系统更容易扩展、更难被破坏？

我记得有一次 code review，看到一位同事写了一大堆虚函数，但仔细一看，那些函数根本不会有多态调用。他纯粹是为了「面向对象」而写。嗯，这种过度设计，比没有设计更可怕。

八、小结

开闭原则的核心就三句话：

  • 对扩展开放——允许通过添加新代码来增加功能
  • 对修改关闭——已有的稳定代码不要动
  • 抽象化是关键——通过抽象接口隔离变化

这个原则说起来简单，做起来需要经验。你可能会问：我怎么知道哪些地方会变化？哪些地方需要抽象？

答案是：一开始你不可能完全知道。没关系，先写一个能跑的版本，等需求变化时，再重构出合适的抽象层。开闭原则不是一次设计出来的，而是在迭代中逐步形成的。

好了，这一讲就到这里。下一讲我们会深入讨论如何在实际项目中应用开闭原则，包括一些具体的代码模式和设计技巧。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →