第1章：设计原则的未来——C++20/23新特性对设计原则的影响

说实话，我写C++快二十年了。从C++98一路摸爬滚打到现在的C++23，每次标准更新都像一次“大扫除”。有些老代码看着就头疼，但新特性用好了，设计原则的落地方式会彻底改变。

这一章，我想聊聊C++20和C++23带来的三个“大杀器”：概念（Concepts）、协程（Coroutines）、模块（Modules）。它们不只是语法糖，而是从底层改变了我们遵循设计原则的方式。

1. 概念（Concepts）：接口设计的“契约”时代

先说说概念。我个人习惯把概念理解为“编译期的接口契约”。以前我们用模板，写出来的代码像“鸭子类型”——只要长得像鸭子，就叫它鸭子。但问题是，编译器报错时那几百行的错误信息，谁看谁头疼。

我在项目中遇到过这样一个场景：一个团队写了一个通用的排序函数，模板参数要求支持operator<。结果有人传了一个自定义类型，忘了重载这个操作符。编译错误刷了满屏，最后定位花了半天。

有了概念，事情就简单了。你可以明确告诉编译器：“我的模板只接受满足某种要求的类型”。这其实就是接口隔离原则的编译期实现。

// C++20 概念示例
template<typename T>
concept Sortable = requires(T a, T b) {
    { a < b } -> std::convertible_to<bool>;
    { a == b } -> std::convertible_to<bool>;
};

template<Sortable T>
void my_sort(std::vector<T>& vec) {
    // 排序实现
}

你想想看，这跟传统的模板写法有什么区别？区别大了。以前你只能靠文档或注释告诉调用者“这个模板需要什么”，现在编译器替你检查。说白了，这就是依赖倒置原则的现代化表达——依赖抽象，而不是具体实现。

2. 协程（Coroutines）：异步设计的“结构化”革命

协程这个东西，我一开始是抗拒的。为什么？因为C++的协程模型太底层了，你得自己实现promise_type、awaitable、awaiter……一堆东西。但用熟了之后，我发现它其实是单一职责原则的绝佳实践。

传统的异步回调写法，一个函数里塞了三个回调，每个回调又调另一个异步函数。代码像意大利面一样，牵一发而动全身。协程把异步逻辑“拉直”了，让代码看起来像同步的。

// C++20 协程示例（简化版）
Task<int> fetch_data() {
    auto request = co_await http_client::get("https://api.example.com/data");
    auto parsed = co_await parse_json(request.body);
    co_return parsed.value;
}

void process() {
    auto task = fetch_data();
    // 协程在后台执行，不阻塞当前线程
}

这里有个关键点：协程让开闭原则更容易实现。你可以新增一个协程函数，而不需要修改现有的异步调度框架。每个协程只负责一件事，组合起来就是完整的业务逻辑。

我曾经在一个网络库中重构过异步代码。原来用回调+状态机，代码量大概2000行。改用协程后，核心逻辑压缩到600行，而且每个协程的职责一目了然。嗯，这里要注意：协程的性能开销比回调略高，但换来的是可维护性的大幅提升。值不值？我觉得值。

3. 模块（Modules）：物理设计的“封装”升级

模块是C++20最让我兴奋的特性。为什么？因为头文件的问题困扰了我整个职业生涯。宏污染、重复定义、编译慢……这些问题在模块面前，基本都解决了。

从设计原则的角度看，模块是接口隔离原则和依赖倒置原则的物理实现。以前你只能通过头文件来“暗示”哪些是公开接口，哪些是内部实现。现在模块可以明确声明：export的是接口，import的是依赖。

// math.ixx 模块接口文件
export module math;

export int add(int a, int b);
export int multiply(int a, int b);

// 内部函数，不导出
int helper(int x) { return x * 2; }

// main.cpp
import math;

int main() {
    return add(3, 4);  // 正确
    // helper(5);      // 错误！helper未导出
}

你想想看，这跟传统的头文件+实现文件有什么区别？区别太大了。传统方式中，即使你把函数声明放在头文件里，别人还是可以通过前向声明或直接包含实现文件来绕过你的“封装”。模块从语言层面杜绝了这种问题。

我个人习惯在大型项目中使用模块来组织代码。每个模块对应一个功能域，模块之间通过import建立依赖关系。这样，依赖关系图就变得清晰可见，循环依赖的问题也更容易被发现。

4. 新特性如何重塑设计原则

我把这三个新特性对设计原则的影响整理了一下，方便你对照参考：

设计原则	传统实现痛点	C++20/23新特性解决方案
单一职责原则	回调函数中职责混杂	协程让每个异步任务独立成函数
开闭原则	模板特化导致代码膨胀	概念约束让扩展更安全
接口隔离原则	头文件暴露过多细节	模块精确控制导出内容
依赖倒置原则	模板隐式依赖难以追踪	概念显式声明依赖要求
里氏替换原则	继承体系脆弱	概念+协程减少继承需求

说白了，新特性不是让你抛弃设计原则，而是给你更好的工具去实现它们。就像你以前用锤子钉钉子，现在给你一把射钉枪——活还是那个活，但效率和质量都上去了。

5. 知识体系总览

下面这张图展示了C++20/23新特性与设计原则之间的关系。我把它画成了一张“影响地图”，方便你理解整体脉络。

从这张图你可以看到，每个新特性都对应着多个设计原则。概念让接口更安全，协程让异步更清晰，模块让封装更彻底。三者合力，让C++的设计原则从“建议”变成了“强制”。

好了，这一章就聊到这里。设计原则不是死的教条，而是活的实践。C++20/23给了我们更好的工具，但最终还是要靠人来做出好的设计。下一章，我会深入聊聊概念在接口设计中的具体应用，到时候见。

---

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