简介《设计模式精解GoF 23种设计模式解析附C实现源码》是一份以PDF形式发布的经典设计模式学习资料面向希望系统掌握23种GoF模式的C开发者、软件工程师及计算机专业学生。文档按创建型、结构型、行为型三类组织逐一解析工厂、抽象工厂、单例、建造者、原型、桥接、适配器、装饰、组合以及责任链、命令、观察者、策略、模板方法等模式结合定义、用途、实现要点与C源码示例帮助读者理解每种模式的适用场景及模式间的联系。压缩包仅含1个PDF文件体积2.52MB目录结构清晰便于离线查阅。目前已有1706人学习下载适合作为设计模式入门与进阶的系统参考。通过研读其中的解析与源码读者能够获得可复用的C实现思路掌握在实际项目中合理选型与组合设计模式的方法从而提升软件的可维护性与扩展性。1. 为什么C开发者最容易把设计模式学成“背书名”我面试过不少C候选人简历上都会写“熟悉23种设计模式”结果聊到实际项目十个里有八个只会说“单例嘛static变量那个”问到“你最常用哪个模式”就是“单例”。这不是个别现象而是C阵营特有的学习误区——把设计模式当成一本知识点清单去背背完就忘用的时候根本想不起来。设计模式这个概念来自GoF的《Design Patterns: Elements of Reusable Object-Oriented Software》1994年出版里面整理了23个模式分创建型、结构型、行为型三大类。这本书的示例语言就有C但那时候的C还带着浓厚的C风格没有STL没有模板库没有智能指针更别说lambda表达式。很多东西在今天看来已经“过时”了比如很多模式的经典实现里要手动管理new/delete、手写拷贝构造、用裸指针做回调这些在现代C里都有更安全、更简洁的替代方案。我见过很多刚入行的C工程师学设计模式时用的都是Java或Python版的教程然后照搬到C里。结果就是在unique_ptr已经大行其道的代码库里还硬生生写出一堆裸指针的工厂函数在std::function和lambda随处可见的现代工程里还手写抽象基类加虚函数去实现策略模式。模式本身没错错的是没搞清楚C这门语言在设计模式上的两个特殊点第一C是同时支持面向对象、泛型、函数式三种范式的多范式语言很多设计模式可以通过不同的范式实现甚至可以用模板在编译期就完成“决策”根本不需要运行时的多态和指针。第二C有RAII资源获取即初始化这个核心机制它天然解决了绝大多数资源管理的痛点而这恰恰是Java/Python里不存在的问题。换句话说很多模式在Java里是为了解决内存泄漏和对象生命周期问题到了C里这个动机本身就已经被语言机制消化掉了。所以这篇东西我不想按“背书名”的路子重新罗列23个模式的定义而是想站在一个常年写C的工程师角度把23种设计模式拆成几条真正有用的主线它们到底在解决什么矛盾、在C里正确长什么样、现代C又如何冲击了传统写法、面试中它们会以一种什么样的真实面目出现。看完这篇文章你能建立起一套自己的模式地图而不是脑子里一盘散沙的23个名词。2. 23种设计模式的真正骨架三组核心矛盾而不是“三大类”GoF把23种模式分成创建型、结构型、行为型三大类这个分法是给图书管理员用的不是给工程师用的。工程里设计模式绕开教科书分类本质上只解决三组矛盾对象怎么创建、对象怎么组合、对象之间怎么协作。每一组矛盾对应的都是一种“变化点”找到变化点模式才能自然浮现而不是先背一个模式名再硬套形状。2.1 创建型模式把“new”从业务代码里剥离出去创建型模式有五种单例、工厂方法、抽象工厂、建造者、原型。它们的核心矛盾只有一个——对象创建的逻辑如果散落在业务代码里一旦创建方式变了比如从单例变成池化、从本地类变成代理类、从每帧new变成缓存复用所有调用方都要跟着改。创建型模式就是在对象创建的外面包一层“间接层”让调用方依赖抽象而不依赖具体构造过程。这五种的差异在于“变化维度”变化的是“创建多少个”——单例模式。变化的是“创建哪种子类”——工厂方法交给子类决定实例化哪个类。变化的是“创建一族相互关联的对象”——抽象工厂比如一套UI框架里按钮、输入框、窗口要统一风格不允许出现Windows按钮配Linux输入框这种混搭。变化的是“复杂对象的组装过程”——建造者比如拼装一台电脑CPU、主板、显卡各自的实现可以千变万化但组装流程是稳定的。变化的是“通过拷贝而不是构造来创建”——原型模式针对深拷贝成本高、构造过程重的场景。C里创建型模式有个其他语言没有的典型优势工厂方法完全可以不用虚函数和继承用模板加函数对象就能实现甚至可以在编译期完成对“该创建哪个对象”的决策。这类实现不仅运行期零开销而且没有继承体系的侵入性这在嵌入式、游戏引擎这类对性能敏感的场景里非常重要。2.2 结构型模式把“类的形状”和“运行时的组合方式”分开看结构型模式有七种适配器、桥接、组合、装饰器、外观、享元、代理。它们在解决另一组矛盾——继承是静态的、编译期的绑定而组合是动态的、运行时的绑定。继承一旦定死一个类的行为就锁死了组合则允许在运行期灵活拼装。结构型模式本质上就是在教你怎么用“组合优于继承”来设计对象的形状。以装饰器和适配器为例这两个模式特别容易混淆原因是它们都在“包一层”。区别在于目的适配器是改变接口的形状让一个不兼容的接口变成调用方期望的接口解决的是“接口不匹配”的问题装饰器是不改变接口只增加行为解决的是“功能动态叠加”的问题。C里适配器的经典例子就是std::stack和std::queue它们不是重新实现一个容器而是适配了std::deque的接口对外只暴露栈或队列的操作。结构型模式里最容易在C里写出性能隐患的是装饰器模式——如果基类有虚函数每一层装饰多一次虚调用层级多的时候开销积少成多。游戏引擎里复杂的装备系统用装饰器实现后往往会在运行期把每一层装饰“拍平”成一个最终对象再参与计算而不是调用时才一层层剥。这类优化在设计模式的书上不会写但实际工程里经常要做这也是“会背模式”和“会用模式”之间的分水岭。2.3 行为型模式对象之间怎么说话决定系统的可维护性行为型模式最多有十一种策略、模板方法、观察者、迭代器、责任链、命令、状态、访问者、中介者、备忘录、解释器。它们解决的核心矛盾是对象间的协作方式——对象之间直接互相依赖系统就耦合成一团通过中介、订阅、命令等方式解耦系统就能独立演化。行为型模式真正的困难不在实现而在“什么时候该用哪个”。观察者模式适合“一改多动”的场景比如UI控件状态变化要通知多个面板刷新命令模式适合“把一次操作封装成可撤销、可重放的对象”比如编辑器的撤销重做本质就是把每一次操作记录成命令对象塞进历史栈状态模式适合“对象行为随内部状态切换而切换”的场景比如TCP连接的状态机、游戏角色的战斗状态。策略模式和状态模式表面上看都是“把一段行为抽出去”区别在于状态模式的状态切换是由状态自身驱动的而策略模式是由外部调用方决定用哪个策略的。这个区别面试经常问搞不清就说明对行为型模式的理解还停留在背定义阶段。行为型模式到了C里还有一个绕不开的泛型实现维度迭代器模式早在C98时代就被STL用模板彻底实现了你在vector、list上用范围for循环时就已经在用迭代器模式只不过实现方式是泛型多态而不是面向对象多态。这就是C设计模式最有趣的地方——很多模式在这门语言里不是“设计出来的”而是“生长出来”的。3. 六个高频模式在C中的正确打开方式23个模式不是平均分布的。我翻过几个大厂的C代码库也聊过不少做服务端、图形、游戏开发的同行实际工程中出现频率最高的差不多只有六个单例、工厂方法含抽象工厂、观察者、策略、状态、模板方法含CRTP变体。把这六个吃透对工作的直接价值远超其他十几个。下面逐个说C里的实现要点和坑。3.1 单例C里最容易被写坏的模式单例在所有模式里名气最大但C里的正确写法也是被讨论得最多的因为涉及线程安全和初始化顺序。经典的懒汉式双检锁DCLPDouble-Checked Locking Pattern在C里是出了名的容易写错——因为指令重排可能导致返回一个未完全初始化的实例除非用atomic配合acquire/release语义。但这个坑在C11之后已经被语言特性填掉了局部static变量的初始化是线程安全的编译器会自动加锁而且不依赖调用者做任何同步处理。所以现代C的单例最简写法就是这样class Singleton { public: static Singleton instance() { static Singleton inst; return inst; } Singleton(const Singleton) delete; Singleton operator(const Singleton) delete; private: Singleton() default; ~Singleton() default; };这里有几个必须强调的细节构造函数和析构函数设为private防止外部再构造拷贝构造和拷贝赋值delete掉防止复制单例通过引用返回而不是指针返回防止调用方误delete。很多老教程还在写返回static指针的版本一旦有人对返回值调用delete程序直接崩溃这种实现不应该再出现了。还有一点单例的析构函数不要做太重的清理工作因为静态对象的析构顺序是不可控的你可能在依赖它的其他静态对象销毁之后才销毁单例访问成员直接未定义行为。解决办法是尽量在main函数退出前手动清理或者干脆依赖操作系统回收资源。3.2 工厂模式C里没有“一个标准实现”网上搜“C工厂模式”你会看到十几种写法各有各的道理。这是正常的因为工厂模式是一种思想而非固定代码模板——核心只有一条把“选择创建哪个类”的逻辑从业务代码中抽出来。最简单的实现可以用std::function加mapclass Product { public: virtual ~Product() default; virtual void use() 0; }; class ProductA : public Product { public: void use() override { /* A的实现 */ } }; class ProductB : public Product { public: void use() override { /* B的实现 */ } }; using FactoryFn std::functionstd::unique_ptrProduct(); std::unordered_mapstd::string, FactoryFn registry { {A, []() { return std::make_uniqueProductA(); }}, {B, []() { return std::make_uniqueProductB(); }} }; auto create [](const std::string type) - std::unique_ptrProduct { auto it registry.find(type); if (it registry.end()) return nullptr; return it-second(); };这个实现的好处是新增一种产品不需要修改create函数本身只需要往map里注册一个std::function符合开闭原则。注意返回值必须用unique_ptr而不是裸指针这是C工厂模式和Java工厂模式最大的区别——用裸指针返回就要调用方负责delete一旦调用方忘记释放内存泄漏就产生了。用unique_ptr把所有权语义写清楚调用方拿到智能指针即RAII托管根本不用记着释放。3.3 观察者模式回调地狱和生命周期问题C里观察者模式最头疼的问题不是“如何通知”而是“被观察者析构时观察者还在不在”。野指针问题在纯面向对象的观察者实现里非常致命。传统的实现是Subject保存一堆Observer*某个Observer被析构之后如果没有触发反注册Subject一调用就是悬空指针崩溃。现代C的解法有三种用weak_ptr托管观察者的引用通知前先lock判断对象是否存活用信号槽库比如Qt的信号槽、Boost.Signals2库自动在观察者析构时断开连接或者用std::function加token的方式手动管理订阅关系。Boost.Signals2的实现思路值得学习——它把“订阅”和“退订”封装成connection对象观察者持有一个connection析构时自动断开这样就杜绝了悬空回调。如果不想引入第三方库可以自己设计一个简单的token机制class Subject { public: using Callback std::functionvoid(const std::string); int subscribe(Callback cb) { listeners_[next_id_] std::move(cb); return next_id_; } void unsubscribe(int id) { listeners_.erase(id); } void notify(const std::string msg) { for (auto [id, cb] : listeners_) { if (cb) cb(msg); } } private: int next_id_ 0; std::unordered_mapint, Callback listeners_; };这个设计的核心思想是订阅者不直接持有观察者对象的指针而是持有一个整数id事件触发时通过id查表找到回调。这样就算订阅者自己先被析构了只要记得在析构函数里调用unsubscribe(id)就不会出现悬空指针问题。这里提醒一句notify的时候如果在回调里触发了unsubscribe会导致迭代器失效稳妥做法是先把listeners_里的回调拷贝一份再遍历或者用map的erase返回值安全遍历。3.4 策略模式和状态模式一对容易混淆的孪生兄弟策略模式在C里的现代实现非常简单——一个std::function成员变量就够了或者一个枚举加switch的映射。根本不需要为每个策略建一个抽象基类再建N个子类除非策略本身还带有自己的状态和数据。判断标准是如果策略只是一段算法用std::function如果策略是有状态的对象用策略类。状态模式跟策略模式共享一个“把行为抽出去”的外壳差异在驱动方式上状态模式里状态对象自己决定“下一个状态是什么”而策略模式里策略的选择权完全在上下文手里。C里实现状态模式时我建议用std::unique_ptr持有当前状态并且让每个状态返回下一个状态对象而不是直接修改上下文的状态指针这样可以避免在状态切换时“谁删谁”的所有权纠葛class TCPConnection; class TCPState { public: virtual ~TCPState() default; virtual std::unique_ptrTCPState handle(TCPConnection ctx) 0; }; class EstablishedState : public TCPState { public: std::unique_ptrTCPState handle(TCPConnection ctx) override; }; void TCPConnection::process() { auto next state_-handle(*this); if (next) { state_ std::move(next); // 旧状态由unique_ptr自动析构 } }关键在于状态切换是“返回新状态”而不是在handle内部直接delete this。这样可以避免状态对象在自身成员函数执行中被销毁这是所有状态机实现里最容易出bug的地方。3.5 模板方法模式C的继承式复用和它的CRTP变体模板方法模式的经典场景是基类定义算法的骨架子类覆盖某些步骤。在C里如果算法步骤比较简单直接用虚函数就够了但如果这段代码运行在游戏循环或者高频路径上虚函数调用的开销就不可忽略了。这时候可以用CRTPCuriously Recurring Template Pattern奇异递归模板模式把动态多态变成静态多态template typename Derived class GameLoop { public: void run() { while (running_) { static_castDerived*(this)-update(); static_castDerived*(this)-render(); } } protected: bool running_ true; }; class MyGame : public GameLoopMyGame { public: void update() { /* 游戏逻辑 */ } void render() { /* 渲染逻辑 */ } };CRTP的好处是零虚函数开销编译器在编译期就能确定调用的是你写的那个update和render还能内联。代价是代码可读性略差而且如果调用链比较复杂模板报错信息会非常折磨人。CRTP是C特有的“模板方法模式”不属于GoF的23个模式但在实际工程中出现的频率非常高很多C库比如Boost内部大量使用它。学设计模式如果只学GoF那23个不学CRTP等于学会了框架却没学会C里最地道的“自定义框架”。4. 现代C对传统模式的“降维打击”哪些模式正在被语言特性替代设计模式的发展和语言进化是互相纠缠的。GoF书里的很多经典写法是针对90年代语言能力的现代C引入了智能指针、lambda、std::function、std::variant、结构化绑定、concepts等大量新特性一些模式的传统实现方式已经被替代甚至被彻底“消灭”。搞清楚哪些被替代、用什么替代是一个C工程师有没有真正理解设计模式本质的试金石。策略模式是被替代得最彻底的一个。传统写法是一个抽象基类加若干具体策略类调用方持有基类指针运行期决定具体策略。现代C里一个lambda表达式就能表达一个策略std::function负责类型擦除调用方的代码简洁到几乎没有“模式感”#include functional #include vector #include algorithm std::functionint(int, int) strategy [](int a, int b) { return a b; }; // 运行期可以随时换掉 strategy [](int a, int b) { return a * b; };命令模式同样受到lambda的冲击。传统命令模式是为了把操作封装成对象以便传递和撤销现在一个std::function对象或者一个无捕获的lambda转成函数指针就能传递行为配合dequefunctionvoid()就能实现简单的撤销栈。只有当命令自身还带着复杂状态比如快照、参数组时才需要设计成真正的类。观察者模式被信号槽库简化前面已经说了。享元模式在C里也有了更自然的面貌——小对象优化SSOSmall String Optimization和内存池本质上就是享元思想的体现大量相同或相似的对象共享底层存储节省内存。std::string的小字符串优化让短字符串直接存在栈上而不分配堆内存这不就是享元模式的现代C实现吗只是没人叫它享元模式而已。最让我感慨的是访问者模式。传统访问者模式用于在不修改类层次结构的条件下增加新操作写法极其繁琐每个可访问类要加一个accept虚函数每个访问者要重载多组visit函数。C17之后有了std::variant加std::visit一行代码就能做同样的事情而且类型安全更好#include variant #include iostream #include string struct Circle { double r; }; struct Square { double side; }; using Shape std::variantCircle, Square; double area(const Shape s) { return std::visit([](const auto shape) { if constexpr (std::is_same_vstd::decay_tdecltype(shape), Circle) { return 3.14159 * shape.r * shape.r; } else { return shape.side * shape.side; } }, s); }这里没有继承、没有虚函数、没有accept却实现了和访问者模式完全等价的目标为一个封闭类型集合添加新操作而不修改原类型。类似的替代关系还有策略模式被std::function替代、命令模式被std::function加lambda替代、工厂模式被std::make_unique/make_shared和自定义注册表替代、代理模式被std::shared_ptr的部分语义替代、备忘录模式被拷贝构造加移动语义部分替代。但要注意被替代不等于要放弃这些模式。替代的本质是语言提供了更底层的、更灵活的表达手段而是不是所有场景都适合替代。在大型遗留代码库、需要跨语言反射、需要结构清晰文档齐全的场景里传统的面向对象实现依然有它的位置。现代C的做法不是“不用设计模式”而是用语言特性去优化模式的实现方式让模式更加轻量、安全、高效。5. 从会背到会用C设计模式的学习路径与面试深挖点讲完模式本身再说说最实际的怎么系统学习、怎么应对面试。我见过太多简历写“熟悉设计模式”结果面试深挖一两层就露馅的。设计模式面试考察的不是“知不知道23个模式的名字”而是考察你在真实工程中怎么识别变化点、怎么做取舍以及C特性的熟练度。5.1 一套实测有效的学习路径如果你现在对设计模式还是一团浆糊不必一上来就啃GoF那种偏老的书啃不下来更不要打开一篇博客从第一个模式抄到最后一个。我建议按下面四步走先建立“问题域”概念。每个模式都是针对一类具体问题的解法学会“对着问题找模式”。比如你发现代码里到处都是new不同地方new的类经常要一起换这时候抽象工厂就在向你招手发现一堆if else都在判断状态然后执行不同行为状态机模式大概率是你要的。用C亲手实现每一个模式但至少要写两种版本传统面向对象版和现代C优化版。传统版是了解模式的原生面貌现代版是理解C特性怎么把模式变得更安全更简洁。两者对比着写你对模式的本质理解会非常深透。去开源项目里找“活体模式”。我经常让身边的学习者把libuv、fmt、grpc、Qt的源码打开搜一搜绝大多数经典设计模式都能在真实代码里找到活例。比如Qt的信号槽就是观察者的工业级实现fmt库里的visitor就是std::variant和访问者的结合很多游戏引擎的组件系统是组合模式加装饰器模式的复合体。看十篇博客不如看一段真实工程代码。自己造一个复杂场景去综合应用。比如设计一个“可插拔的在线支付系统”支付方式用策略模式或工厂模式、支付结果的异步通知用观察者模式、对账流程用模板方法模式、多渠道汇总结算用组合模式。这样一个小型项目就能把六七种模式串起来活学活用远比零散背模式有效。5.2 C设计模式面试的几道高频深挖题面试里最常见的深挖点集中在以下四类题目上每类背后都有C的语法和语义细节第一类单例的线程安全与生命周期面试官常见的问法是从“单例怎么实现”起步一路深挖C11之前怎么保证线程安全C11之后又为什么安全了局部static变量的初始化用的是什么机制答案编译器插入了一个std::call_once之类的同步机制C11标准保证magic static的线程安全初始化。单例析构顺序问题怎么解决能不能用shared_ptr管理单例 这类题考察的是你对C标准时序的了解程度以及是否真的研究过实现细节。第二类工厂模式和依赖注入的对比边界常见问法是“工厂模式和依赖注入有什么区别什么时候用哪个”。合理回答的思路是工厂模式把“创建哪个类的决策”封装在工厂内部依赖注入把“对象由谁创建”的控制权完全交给外部容器调用方不关心创建过程甚至不关心对象何时创建。C里依赖注入没有像Spring那样成熟的容器生态现有框架也远比Java生态弱所以工厂模式和手动构造仍然非常普遍。如果你能结合C的unique_ptr/shared_ptr去讲所有权转移的语义面试官大概率会给你加分。第三类虚函数和模式实现的关系至少会有两三道题绕着虚函数转。比如模板方法模式中虚函数和CRTP各自的开销怎么样动态多态和静态多态分别在什么场景下适用C的虚函数表布局是什么样的多重继承下的偏移是多少我建议你把虚函数表的基本布局理清楚至少知道虚表指针的位置、虚函数调用经过两次间接跳转因为几乎每个模式都用到多态而多态底层机制的理解最能区分“背了模式”和“真正能驾驭C模式”的人。第四类模式组合资深级面试常出“设计一个XX系统你会怎么组合多种模式”这类题目。比如“设计一个游戏战斗系统”优秀答案是角色基类用模板方法定义战斗流程技能效果用策略模式做成可插拔角色状态用状态机管理事件广播Buff生效、技能命中通知用观察者对象创建生成小怪、掉落物用对象池或工厂性能敏感的遍历用迭代器和内存池。答到这里面试官想听到的不是你能列举多少模式而是你的设计有没有考虑耦合度、扩展点和生命周期管理这些才是设计模式的真正价值。5.3 一个容易踩坑的C单例面试实现最后分享一个我面试中让不少人翻车的细节。题目是“写一个线程安全的C单例”大多数人能写出magic static版本并解释线程安全性但当我追问一句“如果这个单例在程序退出时还要写日志你怎么保证析构时还能访问日志组件”很多人就答不上来了。核心问题在于单例作为静态局部对象析构顺序与构造顺序相反而日志组件本身也可能是个单例两者的析构顺序可能颠倒导致其中一个单例析构时访问了另一个已经析构的单例。一个务实的解法是把日志单例和核心单例的析构逻辑放进一个独立的静态对象并加一个显式的shutdown顺序控制或者干脆让日志单例不析构局部static的unique_ptr不调用delete依赖进程退出时OS回收这样在程序退出崩溃的瞬间日志单例的内存仍然有效Logger getLogger() { static Logger* logger new Logger; // 故意不delete进程退出时由OS回收 return *logger; }这个写法看似违反“不要泄漏”但在单例场景下是故意的——只要Logger对象的构建成本可控、析构清理无特殊要求这种“延迟销毁”的写法反而避免了析构顺序崩溃的风险。很多商业软件和服务端程序都是用这个思路保证退出期的稳定性。面试时能把这个逻辑讲清楚比你背二十个设计模式概念都管用。写在最后设计模式在C里的真正身份回头再想“23种设计模式(C)”这个主题最恰当的身份不是一本口诀手册而是培养设计直觉的训练场。每个模式都是前辈们踩过坑之后总结的“模式语言”用来在团队里高效沟通设计意图你说“这里用了观察者”同事立刻明白有事件源、有订阅者、有解耦你说“这里要改写造成策略模式”同事马上懂你发现了if else分支混乱的问题。这种沟通效率的提升才是设计模式无可替代的价值。C可能是23种设计模式最好的学习语言也是最佳的“拆解对象”。它让你不得不思考哪些模式是在弥补语言缺陷哪些模式是因为语言特性天然实现的哪些模式在C11、C14、C17之后已经可以用更安全、更高效的方式写做这种思考得到的收益远大于把23个名字背下来。我自己这些年写C的一个感受是当你不再纠结“该用哪个模式”的时候模式才真正变成了你的肌肉记忆——你只是顺着代码的自然结构走遇到变化点随手包一层遇到冒烟处随手抽象一次回头看代码模式自然浮现出来了。这篇文章起于一份PDF标题但如果能帮你在C设计模式这棵树上找到自己的脉络目的就达到了。本文还有配套的精品资源点击获取