1. 项目概述为什么我们需要重读GoF设计模式如果你是一名有几年经验的C或C开发者可能不止一次在项目里遇到过这样的场景代码越写越乱模块间耦合得像一团乱麻加个新功能要改十几个文件修一个Bug能引出三个新Bug。这时候你或许会想起“设计模式”这个词然后翻出那本经典的《设计模式可复用面向对象软件的基础》也就是GoF那本书但看着那些用Smalltalk或C描述的抽象例子又觉得离自己手头的C项目有点远。这正是我启动这个“设计模式精解”项目的初衷用最贴近系统级开发的C语言把GoF的23种设计模式重新“翻译”一遍并提供可直接编译、运行的源码。设计模式不是银弹更不是用来炫技的复杂框架。它的本质是一套在特定场景下经过无数项目验证的、解决特定设计问题的最佳实践套路。GoF的23种模式就像是给软件架构师和资深开发者准备的一套“围棋定式”。你不必死记硬背每一个模式但当你面对“如何让对象创建更灵活”、“如何让对象间的通信更解耦”、“如何在不修改原有结构的情况下扩展功能”这类问题时这些模式能立刻给你提供经过实战检验的解决方案蓝图。用C语言来实现这些模式尤其具有教学和实战的双重意义。C语言没有原生类和继承这迫使我们更深刻地理解模式的本质——它关乎的是职责的分配、对象的关系和变化的封装而非某种特定语法。通过C的实现你能剥离掉高级语言语法糖的干扰直击面向对象设计思想的精髓组合优于继承、针对接口编程、封装变化点。这对于夯实编程基础、理解大型系统如Linux内核、数据库、游戏引擎中隐含的设计思想有着不可替代的作用。2. 核心设计思路用C语言诠释面向对象精髓很多人误以为设计模式是Java或C等“纯正”面向对象语言的专利。这是一个巨大的误解。面向对象是一种设计思想而语言只是其表达工具。C语言通过结构体struct封装数据通过函数指针function pointer实现多态通过头文件.h声明接口完全能够构建出符合面向对象设计原则的模块化系统。2.1 指导思想从“语法实现”到“思想映射”本项目的核心思路不是机械地将C或Java的示例代码翻译成C语法而是抓住每种模式要解决的核心问题用C语言最地道的方式来实现其设计思想。关键在于以下几个映射关系“类”与“对象”在C中一个struct定义对应一个“类”该struct的实例变量就是一个“对象”。我们将数据成员放在struct内部。“方法”与“多态”这是最精彩的部分。我们在struct内部定义函数指针成员例如void (*draw)(struct Shape*);。这个函数指针就是对象的“方法”。通过为不同的struct实例赋予不同的函数实现就实现了“运行时多态”。这比C的虚函数表vtable更直观地揭示了多态的底层机制。“继承”与“组合”C语言没有语法层面的继承。我们通过“组合”来模拟结构体嵌套子struct的第一个成员是父struct。这保证了内存布局的兼容性可以安全地将子类指针转换为父类指针即“向上转型”。接口实现定义一个只包含函数指针的struct作为“接口”其他struct通过包含这个接口struct并为其函数指针赋值来实现该接口。“封装”通过将struct的定义放在.c文件中在对应的.h文件中只提供前置声明和操作函数即“工厂函数”或“API”我们可以实现“不透明指针”Opaque Pointer达到信息隐藏和接口与实现分离的目的。2.2 项目结构设计为了清晰和可复用每个设计模式的实现都遵循统一的目录结构design-patterns-in-c/ ├── patterns/ │ ├── creational/ # 创建型模式 │ │ ├── factory_method/ │ │ │ ├── factory_method.h │ │ │ ├── factory_method.c │ │ │ └── main.c # 该模式的测试用例 │ │ ├── abstract_factory/ │ │ └── ... │ ├── structural/ # 结构型模式 │ │ ├── adapter/ │ │ ├── bridge/ │ │ └── ... │ └── behavioral/ # 行为型模式 │ ├── strategy/ │ ├── observer/ │ └── ... ├── common/ # 公共头文件和工具 │ └── common_types.h └── build/ # 编译输出目录每个模式的main.c都是一个独立、可编译运行的小例子演示该模式最典型的应用场景。所有代码都力求简洁避免为了“像面向对象”而引入不必要的复杂性。注意在C中管理内存和对象生命周期需要格外小心。每个模式实现中我们都严格遵守“谁创建谁销毁”的原则提供配套的Create和Destroy函数并在注释中明确内存所有权防止内存泄漏。3. 创建型模式精解与C实现创建型模式关注对象的创建机制目标是使系统不依赖于对象创建和组合的具体方式从而提升灵活性和可复用性。3.1 工厂方法模式将对象创建延迟到子类核心问题在编写代码时我们常常需要创建一个对象但无法预知或不想指定它具体的类。比如一个文档编辑器需要创建多种类型的“文档”对象WordDoc, ExcelDoc。C语言实现要点 我们定义一个“产品”接口一个包含操作函数指针的struct以及一个“创建者”接口包含一个创建产品的函数指针。不同的具体创建者struct负责实现这个创建函数返回不同的具体产品。// product.h typedef struct Product Product; struct Product { void (*use)(Product* self); }; // creator.h typedef Product* (*FactoryMethod)(void); // 工厂方法函数指针类型 typedef struct Creator Creator; struct Creator { FactoryMethod factoryMethod; // 这就是工厂方法 Product* (*createProduct)(Creator* self); // 对工厂方法的封装 }; // concrete_creator_a.c Product* createConcreteProductA() { ConcreteProductA* product malloc(sizeof(ConcreteProductA)); product-base.use concreteProductAUse; // 赋值具体函数 // ... 其他初始化 return (Product*)product; } void creatorAInit(Creator* creator) { creator-factoryMethod createConcreteProductA; // 关键注入具体的创建逻辑 }实操心得 工厂方法模式在C中实现的关键是将“创建对象的函数”作为回调函数注入到创建者结构中。这完美体现了“依赖倒置”——高层模块使用产品的代码不依赖低层模块具体产品二者都依赖于抽象Product接口和FactoryMethod函数指针。在嵌入式系统或插件式架构中这种模式常用于根据配置动态加载不同的驱动或算法模块。3.2 抽象工厂模式创建产品家族核心问题需要创建一系列相互关联或依赖的产品对象并且希望确保这些产品是兼容的。例如开发一个UI库需要为“Windows风格”创建一套按钮、文本框、对话框为“Mac风格”创建另一套。C语言实现要点 抽象工厂是一个包含多个工厂方法用于创建不同类型产品的接口。每个具体工厂struct实现这个接口生产属于同一“家族”的所有产品。// abstract_factory.h typedef struct Button Button; typedef struct TextField TextField; typedef struct UIFactory UIFactory; struct UIFactory { Button* (*createButton)(UIFactory* self); TextField* (*createTextField)(UIFactory* self); }; // win_factory.c Button* winCreateButton(UIFactory* self) { return (Button*)createWinButton(); // 创建Windows风格按钮 } TextField* winCreateTextField(UIFactory* self) { ... } void winFactoryInit(UIFactory* factory) { factory-createButton winCreateButton; factory-createTextField winCreateTextField; }注意事项 抽象工厂模式在C中实现时内存管理会变得稍微复杂因为一个工厂创建了多个产品对象。务必在工厂的销毁函数中递归或循环销毁所有由其创建的产品或者明确约定产品对象的生命周期由使用者管理。这个模式在需要保持整个系统风格一致性的场景下非常有用比如游戏中的不同主题科幻、中世纪对应不同的角色、武器、场景建筑工厂。3.3 建造者模式分步构建复杂对象核心问题当一个对象如一份复杂的报告、一台电脑的构建过程非常复杂包含许多步骤和部件并且可能要有不同的表示构建顺序或部件不同时使用构造函数或简单工厂会使得代码冗长且难以阅读。C语言实现要点 我们将对象的构建算法指挥者与其部件的装配过程建造者分离。定义一个“建造者”接口包含构建对象各个部分的函数指针。具体的建造者实现这些函数。指挥者struct持有一个建造者指针并按固定流程调用其构建函数。// builder.h typedef struct ComputerBuilder ComputerBuilder; struct ComputerBuilder { void (*buildCPU)(ComputerBuilder* self); void (*buildMemory)(ComputerBuilder* self); void (*buildStorage)(ComputerBuilder* self); Computer* (*getResult)(ComputerBuilder* self); // 返回最终产品 Computer* product; // 建造者内部维护正在构建的产品 }; // director.c typedef struct Director Director; struct Director { ComputerBuilder* builder; }; void constructGamingPC(Director* director) { director-builder-buildCPU(director-builder); director-builder-buildMemory(director-builder); // ... 可能先装内存再装显卡顺序由指挥者定 director-builder-buildStorage(director-builder); }常见问题 建造者模式与工厂模式的区别是什么工厂模式关注最终产品是什么而建造者模式关注产品是如何一步步组装出来的它提供了更精细的控制。在C语言中实现时建造者struct内部通常需要保存一个“半成品”对象的指针每一步构建函数都修改这个半成品。最后通过getResult函数将其返回并最好将建造者内部的指针置空避免重复返回或误销毁。4. 结构型模式精解与C实现结构型模式关注如何组合类和对象以形成更大的结构主要分为类结构型模式通过继承和对象结构型模式通过组合在C中我们主要实现后者。4.1 适配器模式让不兼容的接口协同工作核心问题你有一个现成的、功能完好的类或模块比如一个第三方日志库但它的接口与你的系统当前期望的接口不匹配。重写这个模块成本太高不改动自己的系统又无法使用它。C语言实现要点 适配器就像一个“转接头”。我们定义一个新的struct适配器它内部包含一个需要被适配的旧对象指针同时实现系统所期望的新接口。在实现新接口的函数时适配器内部调用旧对象的方法可能还需要进行一些数据格式的转换。// target.h (系统期望的接口) typedef struct Logger Logger; struct Logger { void (*logMessage)(Logger* self, const char* msg); }; // legacy_logger.h (需要被适配的旧组件) typedef struct LegacyLogger LegacyLogger; struct LegacyLogger { void (*output)(LegacyLogger* self, int priority, const char* tag, const char* msg); }; // logger_adapter.c typedef struct LoggerAdapter LoggerAdapter; struct LoggerAdapter { Logger base; // 实现目标接口 LegacyLogger* legacyLogger; // 持有被适配者 }; static void adapterLogMessage(Logger* self, const char* msg) { LoggerAdapter* adapter (LoggerAdapter*)self; // 转换调用将新的logMessage调用转换为旧组件的output调用 adapter-legacyLogger-output(adapter-legacyLogger, 1, APP, msg); } LoggerAdapter* createLoggerAdapter(LegacyLogger* legacyLogger) { LoggerAdapter* adapter malloc(sizeof(LoggerAdapter)); adapter-base.logMessage adapterLogMessage; // 赋值适配后的函数 adapter-legacyLogger legacyLogger; return adapter; }实操心得 适配器模式在集成旧代码、使用第三方库时极其常见。在C中由于缺乏接口的显式声明适配器模式有时会和“外观模式”混淆。关键区别在于适配器主要解决接口不兼容问题它包装一个对象而外观模式是为一组复杂的子系统提供一个简化接口它可能包装多个对象。实现时要注意被适配对象生命周期的管理适配器不应销毁不属于它的对象。4.2 桥接模式将抽象与实现解耦核心问题当一个类抽象有多个变化维度如“形状”和“颜色”如果用继承来实现所有组合RedCircle, BlueSquare...会导致类爆炸M x N个类。桥接模式将这两个维度分离使它们可以独立变化。C语言实现要点 定义“抽象”部分和“实现”部分两个独立的接口。抽象部分如Shape持有一个指向实现部分如Color的指针。抽象部分的派生类如Circle通过调用实现部分接口的方法来完成自己的操作。// implementor.h (实现部分接口) typedef struct Color Color; struct Color { void (*fill)(Color* self); }; // abstraction.h (抽象部分接口) typedef struct Shape Shape; struct Shape { Color* color; // 桥接的关键持有实现部分的引用 void (*draw)(Shape* self); }; // circle.c (精化抽象) typedef struct Circle Circle; struct Circle { Shape base; int x, y, radius; }; static void circleDraw(Shape* self) { Circle* circle (Circle*)self; printf(Drawing Circle at (%d, %d) with radius %d. , circle-x, circle-y, circle-radius); // 委托给实现部分 self-color-fill(self-color); }为什么用桥接假设我们新增一个Triangle形状或者新增一个Texture填充方式。使用桥接模式我们只需要增加一个Triangle类和一个Texture类系统总类数为MN。而用继承则需要为Triangle创建RedTriangle,BlueTriangle,TextureTriangle... 类数量是M*N。桥接模式极大地提升了系统的可扩展性。在C图形库、跨平台UI框架抽象是控件实现是Windows/Linux/Mac的具体绘制中这种模式是基石。4.3 组合模式统一处理树形结构核心问题需要处理树形结构的对象如文件系统、GUI容器希望用一致的方式处理单个对象和对象组合。例如对“文件”和“文件夹”都能进行“计算大小”的操作。C语言实现要点 定义一个统一的组件接口Component其中声明了像add,remove,getChild,operation这样的方法。叶子节点Leaf和容器节点Composite都实现这个接口。叶子节点实现operation但add和remove可能是空操作或报错容器节点实现operation通常是遍历所有子组件调用它们的operation并管理一个子组件列表。// component.h typedef struct FileSystemNode FileSystemNode; struct FileSystemNode { char name[256]; void (*print)(FileSystemNode* self, int depth); // 统一的操作 // 对于组合节点还需要以下管理子节点的函数指针 void (*addChild)(FileSystemNode* self, FileSystemNode* child); void (*removeChild)(FileSystemNode* self, FileSystemNode* child); // 组合节点内部会维护一个子节点链表 struct FileSystemNode* children; struct FileSystemNode* nextSibling; // 用于链表 }; // directory.c (组合节点) static void directoryPrint(FileSystemNode* self, int depth) { printIndent(depth); printf([Dir] %s\n, self-name); // 递归打印所有子节点 FileSystemNode* child self-children; while (child ! NULL) { child-print(child, depth 1); child child-nextSibling; } }注意事项 在C中实现组合模式最大的挑战在于内存管理和数据结构的维护。组合节点需要负责其子节点链表的创建、插入、删除和销毁。必须非常小心地处理指针避免内存泄漏和悬空指针。一个实用的技巧是在组件接口中定义一个destroy函数组合节点的destroy需要递归销毁所有子节点。这个模式是处理任何层次化数据的利器从组织架构图到语法分析树都能看到它的身影。5. 行为型模式精解与C实现行为型模式关注对象之间的职责分配和通信方式描述算法和对象间职责的分配。5.1 策略模式定义算法家族使其可互换核心问题一个系统需要在多种算法中选择一种如不同的排序算法、不同的压缩算法、不同的支付方式。如果将这些算法硬编码在类中会使类变得复杂且难以维护和扩展。C语言实现要点 将每个算法封装成一个独立的“策略”struct它们实现相同的策略接口通常是一个执行算法的函数指针。上下文Contextstruct持有一个策略指针。客户端可以在运行时给上下文配置不同的策略从而改变其行为。// strategy.h typedef struct CompressionStrategy CompressionStrategy; struct CompressionStrategy { void (*compress)(CompressionStrategy* self, const char* input, char* output); }; // context.h typedef struct Compressor Compressor; struct Compressor { CompressionStrategy* strategy; void (*setStrategy)(Compressor* self, CompressionStrategy* strategy); void (*executeCompression)(Compressor* self, const char* input, char* output); }; // zip_strategy.c static void zipCompress(CompressionStrategy* self, const char* input, char* output) { printf(Compressing %s using ZIP algorithm into %s...\n, input, output); // 实际的ZIP压缩逻辑 } // compressor.c void compressorExecute(Compressor* self, const char* input, char* output) { if (self-strategy NULL) { fprintf(stderr, No compression strategy set!\n); return; } self-strategy-compress(self-strategy, input, output); }实操心得 策略模式是“开闭原则”的完美体现。当需要新增一种算法时你只需要增加一个新的策略struct并实现接口而无需修改上下文或客户端的代码。在C语言中这通常通过动态库.so或.dll加载不同的策略模块来实现插件化架构。例如一个图像处理软件可以动态加载“锐化”、“模糊”、“边缘检测”等不同的滤镜策略。5.2 观察者模式建立对象间一对多的依赖核心问题当一个对象主题的状态发生改变时所有依赖于它的对象观察者都需要得到通知并自动更新。例如GUI中的按钮主题被点击时多个对话框元素观察者需要刷新。C语言实现要点 主题struct维护一个观察者链表并提供attach注册、detach注销和notify通知的函数指针。观察者struct实现一个统一的更新接口如update函数指针。当主题状态变化时它遍历观察者链表调用每个观察者的update方法。// observer.h typedef struct Observer Observer; struct Observer { void (*update)(Observer* self, void* subject); // subject通常是主题指针用于获取新状态 }; // subject.h typedef struct Subject Subject; struct Subject { Observer* observerListHead; // 观察者链表头 void (*attach)(Subject* self, Observer* observer); void (*detach)(Subject* self, Observer* observer); void (*notify)(Subject* self); int state; // 主题的状态 }; // concrete_subject.c void subjectNotify(Subject* self) { Observer* current self-observerListHead; while (current ! NULL) { current-update(current, (void*)self); // 将自身指针作为参数传递 current current-next; // 假设Observer有next指针 } }常见问题与排查内存与生命周期观察者必须确保在销毁前从主题中注销自己否则主题会持有野指针。一种稳健的做法是在观察者的销毁函数中自动调用主题的detach。通知顺序与性能notify时遍历链表观察者的更新顺序是不确定的。如果顺序重要可能需要使用更复杂的数据结构如优先级队列。另外如果观察者很多或更新操作很重频繁通知可能导致性能问题。可以考虑引入“脏标志”或批量更新机制。循环引用主题持有观察者链表观察者的update方法又可能回调主题容易造成循环引用。在C中这可能导致难以释放内存需要仔细设计解除注册的时机。这个模式是事件驱动系统的核心从MVC框架到硬件中断处理其思想无处不在。5.3 责任链模式让多个对象都有机会处理请求核心问题一个请求如审批流程、错误处理需要经过多个对象的处理但你不希望请求的发送者与具体的接收者耦合也不想在代码中写死处理顺序。C语言实现要点 定义一个处理者接口Handler包含一个处理请求的函数指针和一个指向下一个处理者的指针后继者。每个具体处理者struct实现这个接口。在它的处理函数中如果自己能处理就处理否则将请求传递给后继者。// handler.h typedef struct SupportHandler SupportHandler; struct SupportHandler { SupportHandler* nextHandler; // 责任链中的下一个节点 void (*setNext)(SupportHandler* self, SupportHandler* next); void (*handleRequest)(SupportHandler* self, const char* request); }; // level1_support.c (具体处理者) static void level1HandleRequest(SupportHandler* self, const char* request) { if (strstr(request, password reset) ! NULL) { printf(Level 1 Support: Handling password reset request.\n); // 处理请求... } else { printf(Level 1 Support: Cannot handle. Passing to next level.\n); if (self-nextHandler ! NULL) { self-nextHandler-handleRequest(self-nextHandler, request); } else { printf(No handler can process this request: %s\n, request); } } }为什么用责任链它解耦了请求发送者和接收者。发送者只需要把请求交给链的第一个节点。你可以动态地修改链中处理者的顺序或增删处理者而无需修改发送者代码。在C语言实现的网络服务器中责任链模式常用于HTTP请求处理管道认证、日志、压缩、路由等中间件或者编译器的错误/警告处理流程。6. 模式综合应用与C项目实战心得理解了单个模式是第一步但真正的功力体现在如何将它们有机地组合起来解决实际项目中更复杂的问题。在C语言项目中由于缺乏语言层面的直接支持这种组合应用更需要清晰的架构设计。6.1 模式组合案例一个简易配置解析器假设我们需要一个配置解析器它能从不同来源文件、命令行、环境变量读取配置并支持不同格式JSON、INI、YAML。我们可以这样组合模式抽象工厂模式用于创建“配置源”和“格式解析器”的产品家族。例如JsonFileFactory生产FileSource和JsonParserIniCmdFactory生产CommandLineSource和IniParser。确保来源和解析器兼容。策略模式每个解析器JsonParser,IniParser本身就是一个策略。配置读取上下文可以根据文件扩展名动态选择解析策略。建造者模式配置对象的构建可能很复杂嵌套结构、默认值填充。可以使用一个ConfigBuilder来逐步构建最终的配置对象。观察者模式当配置文件被修改时通知所有依赖该配置的模块如日志系统、网络连接池进行热更新。在这个案例中抽象工厂负责创建一组协作对象策略模式提供了算法解析的可变性建造者模式控制复杂对象的构建过程观察者模式实现了动态更新。这些模式各司其职共同构建了一个灵活、可扩展的配置系统。6.2 C语言实现设计模式的独家避坑指南经过大量代码实践我总结出在C语言中应用设计模式时最容易踩的几个坑以及应对策略内存管理的泥潭这是C语言永恒的主题。设计模式中对象关系复杂容易导致所有权混乱。明确所有权为每个“创建”函数如createXXX配对一个“销毁”函数destroyXXX。在头文件注释中清晰说明谁调用create谁就负责调用destroy。谨慎使用共享指针如果一个对象被多个其他对象引用如观察者模式中的Subject考虑使用引用计数。或者约定一个“主所有者”其他为“弱引用”主所有者负责销毁。利用Valgrind或AddressSanitizer这是必须的。在编写每个模式的示例代码后立即用这些工具进行内存检查确保无泄漏、无非法访问。函数指针初始化的遗漏这是C实现多态最常见的运行时错误。你创建了一个对象struct却忘记给它的函数指针成员赋值。强制初始化函数不要让客户端代码直接malloc后赋值。为每个“类”提供统一的XXX_init()函数在这个函数内确保所有函数指针都被正确赋值即使是赋值为NULL。断言检查在关键的函数指针被调用前使用assert(handler-callback ! NULL)进行检查在调试阶段快速发现问题。“面向对象”过度设计不要为了模式而模式。C语言的强项在于效率和直接控制。如果一段逻辑非常简单用几个if-else和函数调用就能清晰表达强行套用模式只会增加不必要的间接层和复杂度。评估标准问自己这个模块未来变化的可能性有多大如果变化可能性低直接实现。如果预计会有多个维度变化如算法、平台、格式再引入模式来封装变化点。头文件循环依赖当模式之间相互引用时如Observer需要知道SubjectSubject又要引用Observer容易产生头文件#include死循环。使用不完整类型声明在头文件中大量使用前置声明typedef struct X X;仅在需要知道结构体大小的.c文件中#include对应的头文件。依赖倒置让高层模块和低层模块都依赖于抽象接口只包含函数指针的struct接口头文件不依赖任何具体实现。6.3 从模式到架构在大型C项目中落地在大型C项目如嵌入式系统、数据库、网络服务器中设计模式很少孤立出现它们往往是系统架构的组成部分。插件系统工厂方法抽象工厂策略模式。主程序定义插件接口抽象工厂每个动态库.so/.dll是一个具体工厂在库的初始化函数中向主程序注册自己。主程序通过工厂创建插件策略对象并使用。这是保持核心框架稳定又能无限扩展功能的经典架构。事件处理引擎观察者模式责任链模式命令模式。事件作为对象命令被产生提交给一个全局的事件管理器责任链的起点管理器将事件分发给一系列已注册的事件处理器观察者/责任链节点。处理器可以处理、过滤或转发事件。这种架构在GUI系统和游戏引擎中非常普遍。状态机实现状态模式是实现复杂状态机的标准方式。每个状态是一个独立的struct实现进入、退出、事件处理等函数。上下文struct持有当前状态指针。当事件发生时委托给当前状态处理状态处理函数可以返回下一个状态从而实现状态转移。这对于协议解析如TCP连接状态和游戏角色AI非常有效。最后我想强调的是学习设计模式的最终目的不是记住23种模式的名称和结构而是培养一种“识别和封装变化”的思维习惯。当你面对一个设计问题时能下意识地想到“哦这里的变化点是这个我可以用那个模式来隔离它。” 这时这些模式才真正内化成了你的设计能力。而通过用C语言这把“手术刀”去解剖它们你对这种能力的掌握会比停留在高级语言语法层面深刻得多。我的所有源码都提供了详尽的注释和测试用例建议你clone下来不是阅读而是动手编译、修改、调试甚至尝试打破它再修复这才是掌握设计精髓的不二法门。