1. 项目概述从“new”的困境到设计模式的优雅解耦在C面向对象编程的旅途中我们迟早会撞上这样一个经典的“泥潭”你的代码里散落着大量的new关键字它们像钉子一样将具体的类名和创建逻辑死死地钉在了业务代码里。想象一下你正在开发一个图形编辑器代码里到处都是new Circle()、new Rectangle()、new Triangle()。今天产品经理说我们要加一个五角星Star你不得不满世界去找那些new的地方小心翼翼地修改。明天又说Circle的构造参数要变你又是一通焦头烂额的查找和替换。这种代码的“坏味道”我们称之为“紧耦合”——创建对象的责任和对象的使用者绑得太死了牵一发而动全身。简单工厂模式和工厂方法模式就是为解决这个“创建之痛”而生的两种经典设计模式。它们不是什么高深莫测的黑魔法而是前辈们在无数个加班夜里从痛苦的重复劳动中提炼出的智慧结晶。简单工厂模式就像一个万能的前台你告诉它你要什么比如“画个圆形”它就去后台帮你把对应的“产品”Circle对象拿出来给你。而工厂方法模式则更进一步它为每一类产品都设立了一个专属的“车间主任”工厂接口由具体的“车间”子类工厂来决定生产什么。今天我们就来亲手用C实现它们看看如何把混乱的new整理成清晰、可扩展的创建流水线。2. 简单工厂模式集中管理的“对象便利店”2.1 模式动机与核心思想简单工厂模式的核心思想非常简单将对象的创建过程封装到一个单独的类中。这个类就像一个中央厨房客户端也就是使用对象的代码不需要知道汉堡、薯条是怎么做出来的它只需要告诉厨房“我要一个汉堡”厨房就会把做好的汉堡递出来。这样做最大的好处是职责分离创建对象的复杂逻辑被隔离了客户端代码变得干净只关心如何使用对象而不关心对象从哪来、怎么来。2.2 经典场景图形绘制系统让我们用一个最直观的例子来切入。假设我们有一个图形绘制系统需要支持多种形状比如圆形、矩形。最原始也是最糟糕的写法可能是这样的// 糟糕的紧耦合示例 void drawShape(const std::string type) { if (type circle) { Circle* circle new Circle(); circle-draw(); delete circle; } else if (type rectangle) { Rectangle* rect new Rectangle(); rect-draw(); delete rect; } // 每增加一种新形状这里就要加一个if分支 }这段代码的问题显而易见drawShape函数承担了太多责任判断类型、创建对象、使用对象并且对Circle、Rectangle这些具体类名产生了直接依赖。简单工厂模式就是来收拾这个烂摊子的。2.3 C实现详解首先我们定义所有图形的抽象基类这是多态的基础。// Shape.h - 抽象产品接口 #ifndef SHAPE_H #define SHAPE_H #include iostream class Shape { public: virtual ~Shape() {} // 虚析构函数确保正确释放子类资源 virtual void draw() const 0; // 纯虚函数定义图形绘制的接口 }; #endif // SHAPE_H接着实现两种具体的图形产品。// Circle.h / Circle.cpp #ifndef CIRCLE_H #define CIRCLE_H #include Shape.h class Circle : public Shape { public: void draw() const override { std::cout Drawing a Circle. std::endl; } }; #endif // CIRCLE_H// Rectangle.h / Rectangle.cpp #ifndef RECTANGLE_H #define RECTANGLE_H #include Shape.h class Rectangle : public Shape { public: void draw() const override { std::cout Drawing a Rectangle. std::endl; } }; #endif // RECTANGLE_H现在重头戏来了——简单工厂类。它的核心是一个静态方法根据传入的参数创建对应的对象。// SimpleShapeFactory.h #ifndef SIMPLE_SHAPE_FACTORY_H #define SIMPLE_SHAPE_FACTORY_H #include Shape.h #include Circle.h #include Rectangle.h #include string #include stdexcept // 用于异常处理 class SimpleShapeFactory { public: // 静态工厂方法根据类型字符串创建对应的Shape对象 static Shape* createShape(const std::string shapeType) { if (shapeType CIRCLE) { return new Circle(); } else if (shapeType RECTANGLE) { return new Rectangle(); } else { // 更好的做法是抛出一个明确的异常而不是返回nullptr throw std::invalid_argument(Unsupported shape type: shapeType); } } }; #endif // SIMPLE_SHAPE_FACTORY_H最后看看客户端代码变得多么清爽// main.cpp #include SimpleShapeFactory.h #include memory // 使用智能指针管理资源 int main() { try { // 客户端只需要知道工厂和产品接口完全不知道Circle、Rectangle的存在 std::unique_ptrShape shape1(SimpleShapeFactory::createShape(CIRCLE)); shape1-draw(); // 输出: Drawing a Circle. std::unique_ptrShape shape2(SimpleShapeFactory::createShape(RECTANGLE)); shape2-draw(); // 输出: Drawing a Rectangle. // 尝试创建不支持的形状会抛出异常 // std::unique_ptrShape shape3(SimpleShapeFactory::createShape(TRIANGLE)); } catch (const std::exception e) { std::cerr Error: e.what() std::endl; } return 0; }注意上面的示例中工厂返回的是原始指针。在现代C中更推荐返回std::unique_ptrShape将资源管理的责任也一并封装进工厂彻底避免内存泄漏。我们可以将createShape的返回值改为std::unique_ptrShape内部使用std::make_unique来创建对象。2.4 模式结构与优缺点分析简单工厂模式的结构非常简单通常包含三个角色工厂类SimpleShapeFactory核心负责创建所有具体产品实例。它拥有一个静态方法或普通方法该方法根据传入的参数如字符串、枚举进行条件判断决定实例化哪个具体类。抽象产品接口Shape定义了产品对象的公共接口所有具体产品都必须实现它。这是客户端依赖的唯一类型。具体产品类Circle, Rectangle实现了抽象产品接口是工厂最终创建的对象。它的优点非常突出职责清晰将对象的创建和使用分离客户端无需关心创建细节。初步解耦客户端只依赖抽象产品Shape和工厂类不依赖具体的Circle、Rectangle降低了系统的耦合度。易于管理所有创建逻辑集中在一处便于统一管理和修改例如引入对象池、单例等。但它的缺点也同样明显这也是它被称为“静态工厂”的原因违反开闭原则这是最致命的缺点。开闭原则要求“对扩展开放对修改关闭”。当我们需要增加一个新的产品比如Triangle时我们必须修改工厂类SimpleShapeFactory中的createShape方法增加一个新的if分支。这违反了“修改关闭”的原则。工厂类职责过重随着产品种类的增加工厂方法会变成一个庞大的if-else或switch语句难以维护。静态方法限制使用静态方法使得工厂类难以继承和扩展无法基于工厂类形成多态。简单工厂模式适用于产品种类相对固定、不太可能频繁增加的系统。它是一个很好的起点但当变化来临时我们就需要更强大的模式——工厂方法模式。3. 工厂方法模式将创建权下放的“多态工厂”3.1 模式动机与核心思想工厂方法模式是对简单工厂模式的深化和抽象。它解决了简单工厂模式的核心痛点——违反开闭原则。工厂方法模式的核心思想是定义一个用于创建对象的接口但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。听起来有点绕用我们之前的比喻来说就是简单工厂是一个万能前台而工厂方法模式则是设立了一个“工厂经理”的岗位接口然后为每种产品招聘一个专门的“车间主任”具体工厂。客户端需要产品时先找到对应的“车间主任”由他来负责生产。这样要增加新产品比如三角形我们不需要修改任何现有工厂的代码只需要新招聘一个“三角形车间主任”即可。3.2 经典场景演进支持多图形与扩展继续我们的图形编辑器。现在需求升级了我们不仅要画平面图形未来还可能画三维图形甚至不同风格的图形如粗线条风格、虚线风格。简单工厂的集中判断逻辑会迅速膨胀到无法维护。工厂方法模式正是为此而生。3.3 C实现详解首先抽象产品接口Shape保持不变。具体产品Circle和Rectangle也保持不变。关键的变化在于工厂。我们不再使用一个具体的工厂类而是定义一个抽象的工厂接口。// ShapeFactory.h - 抽象工厂接口 #ifndef SHAPE_FACTORY_H #define SHAPE_FACTORY_H #include Shape.h class ShapeFactory { public: virtual ~ShapeFactory() {} // 工厂方法由子类实现具体创建逻辑 virtual Shape* createShape() const 0; }; #endif // SHAPE_FACTORY_H接下来为每一种具体的产品创建一个对应的具体工厂类。每个工厂只负责创建一种产品。// CircleFactory.h #ifndef CIRCLE_FACTORY_H #define CIRCLE_FACTORY_H #include ShapeFactory.h #include Circle.h class CircleFactory : public ShapeFactory { public: Shape* createShape() const override { return new Circle(); // 专注于创建Circle对象 } }; #endif // CIRCLE_FACTORY_H// RectangleFactory.h #ifndef RECTANGLE_FACTORY_H #define RECTANGLE_FACTORY_H #include ShapeFactory.h #include Rectangle.h class RectangleFactory : public ShapeFactory { public: Shape* createShape() const override { return new Rectangle(); // 专注于创建Rectangle对象 } }; #endif // RECTANGLE_FACTORY_H现在客户端代码的使用方式发生了变化。它需要先决定使用哪个工厂然后通过工厂接口来创建产品。// main.cpp - 使用工厂方法模式 #include CircleFactory.h #include RectangleFactory.h #include iostream #include memory #include vector void renderScene(const ShapeFactory factory) { // 客户端代码只依赖于抽象工厂和抽象产品 std::unique_ptrShape shape(factory.createShape()); shape-draw(); } int main() { // 创建具体的工厂对象 CircleFactory circleFactory; RectangleFactory rectFactory; std::cout Using Factory Method Pattern: std::endl; renderScene(circleFactory); // 输出: Drawing a Circle. renderScene(rectFactory); // 输出: Drawing a Rectangle. // 动态使用工厂的示例 std::vectorShapeFactory* factories {circleFactory, rectFactory}; for (auto factory : factories) { std::unique_ptrShape shape(factory-createShape()); shape-draw(); } return 0; }现在如果我们需要增加一个Triangle产品应该怎么做创建具体产品类Triangle继承自Shape。创建具体工厂类TriangleFactory继承自ShapeFactory实现createShape()返回new Triangle()。完毕我们没有修改任何现有的CircleFactory、RectangleFactory或ShapeFactory接口。系统完全符合开闭原则。3.4 模式结构与深度解析工厂方法模式包含四个角色抽象产品ProductShape定义产品的接口。具体产品ConcreteProductCircle,Rectangle实现抽象产品接口。抽象工厂CreatorShapeFactory声明工厂方法createShape该方法返回一个抽象产品类型的对象。它可以定义该方法的默认实现返回一个默认产品也可以将其定义为纯虚函数。具体工厂ConcreteCreatorCircleFactory,RectangleFactory重写工厂方法返回一个具体产品的实例。工厂方法模式的优点完全符合开闭原则这是最大的优势。增加新产品时只需添加新的具体产品和具体工厂无需修改现有代码扩展性极佳。多态性客户端代码完全针对抽象工厂和抽象产品编程具体工厂和具体产品的变化被隔离。这使得系统可以在不修改客户端代码的情况下切换或配置不同的产品族。职责进一步细化每个具体工厂只负责创建一种产品符合单一职责原则。工厂方法模式的缺点类的数量爆炸每增加一个产品就需要增加一个具体产品类和一个具体工厂类。在大型系统中这会导致类的数量成倍增加增加系统的复杂度和理解成本。增加了抽象层引入了额外的抽象工厂层对于简单场景来说可能显得有些“过度设计”。3.5 参数化工厂方法一种灵活的变体标准的工厂方法模式是“一个工厂对应一个产品”。但有时我们可能希望一个工厂能根据参数创建不同的产品类似简单工厂同时又保持扩展性。这可以通过在抽象工厂接口中增加参数来实现但需要谨慎设计避免走回简单工厂的老路在方法内写if-else。一种更优雅的方式是结合“注册表”或“映射”。抽象工厂提供一个注册和获取工厂的方法具体工厂在启动时向全局注册表注册自己。客户端通过产品类型键从注册表中获取对应的工厂再创建产品。这样既保持了扩展性又提供了类似简单工厂的便捷调用方式。这通常被视为工厂方法模式与抽象工厂模式或反射机制的结合应用在C中实现起来稍复杂但非常强大。4. 两种模式的对比与选型指南简单工厂模式和工厂方法模式经常被拿来比较理解它们的本质区别是正确选型的关键。特性维度简单工厂模式工厂方法模式核心角色一个具体工厂类包含创建所有产品的静态/普通方法。一个抽象工厂接口和多个具体工厂类每个具体工厂负责一种产品。创建逻辑集中在工厂类的单个方法中通过条件判断if-else/switch决定创建哪种产品。分散在各个具体工厂类中每个工厂类独立实现自己的创建逻辑。扩展方式违反开闭原则。增加新产品必须修改工厂类的源代码。符合开闭原则。增加新产品只需新增具体产品类和具体工厂类无需修改已有代码。客户端依赖依赖具体工厂类。依赖抽象工厂接口和抽象产品接口。类数量少1个工厂类 n个产品类。多n个工厂类 n个产品类 1个抽象工厂接口。适用场景产品种类少且稳定创建逻辑简单不需要频繁扩展。适合作为复杂工厂模式的入门或过渡方案。产品种类多或可能频繁增加系统需要良好的扩展性和灵活性。是许多框架和库如Qt的QStyle中常用的模式。设计原则主要体现了“封装变化”和“单一职责”。完美体现了“开闭原则”、“依赖倒置原则”和“多态”。选型心法如果你能确定产品类型基本固定几年内都不会大变比如一个内部工具只处理有限的几种文件格式那么简单工厂的简洁性更有优势。它用最少的代码解决了核心的耦合问题。如果你在开发一个框架、库或者一个需要长期迭代、功能会不断丰富的应用那么工厂方法模式几乎是必选。它为未来的变化预留了标准的扩展插槽。今天多写几个类是为了明天不用通宵改代码。当创建逻辑本身非常复杂或者需要进行复杂的初始化、配置时即使产品种类不多也值得用一个专门的工厂类可以是简单工厂来封装这比把创建代码散落在客户端各处要好得多。在C中还需要考虑对象所有权的生命周期。无论是简单工厂还是工厂方法返回原始指针在现代C中都已不推荐。更佳实践是让工厂方法返回std::unique_ptrProduct将资源管理的责任也封装起来。如果需要有共享所有权的场景则可以返回std::shared_ptrProduct。5. 实战进阶结合现代C特性的优雅实现5.1 使用智能指针管理资源原始指针管理内存容易出错。让我们用std::unique_ptr改造我们的工厂方法模式这是现代C的标配。// ShapeFactory.h (Modern) #ifndef SHAPE_FACTORY_MODERN_H #define SHAPE_FACTORY_MODERN_H #include memory #include Shape.h class ShapeFactory { public: virtual ~ShapeFactory() default; // 工厂方法返回unique_ptr明确所有权转移给调用者 virtual std::unique_ptrShape createShape() const 0; }; #endif // SHAPE_FACTORY_MODERN_H// CircleFactory.cpp (Modern) #include CircleFactory.h #include memory std::unique_ptrShape CircleFactory::createShape() const { // 使用std::make_unique进行创建C14及以上 return std::make_uniqueCircle(); }客户端使用起来也更安全// 客户端代码 CircleFactory cf; auto shape cf.createShape(); // shape是std::unique_ptrShape shape-draw(); // 无需手动deleteshape离开作用域自动释放内存5.2 使用函数对象或Lambda作为轻量级工厂对于极其简单的创建逻辑有时我们不想为每个产品都定义一个完整的工厂类。C的函数对象仿函数或Lambda表达式可以作为一种轻量级的工厂。// 使用函数对象作为工厂 class ShapeCreator { public: virtual ~ShapeCreator() default; virtual std::unique_ptrShape operator()() const 0; }; class CreateCircle : public ShapeCreator { public: std::unique_ptrShape operator()() const override { return std::make_uniqueCircle(); } }; // 使用Lambda和std::function存储工厂逻辑 using ShapeFactoryFunc std::functionstd::unique_ptrShape(); std::mapstd::string, ShapeFactoryFunc factoryRegistry; factoryRegistry[circle] []() { return std::make_uniqueCircle(); }; factoryRegistry[rectangle] []() { return std::make_uniqueRectangle(); }; auto shape factoryRegistry[circle](); // 创建圆形这种方式非常灵活特别适合与配置系统结合动态注册和创建对象。5.3 处理对象构造参数工厂模式的一个常见需求是产品构造时需要参数。我们的工厂方法需要能够传递这些参数。// 带参数的Shape例如圆心和半径 class ParamCircle : public Shape { public: ParamCircle(double x, double y, double r) : centerX(x), centerY(y), radius(r) {} void draw() const override { /* ... */ } private: double centerX, centerY, radius; }; // 对应的工厂也需要支持参数 class ParamCircleFactory : public ShapeFactory { public: // 工厂方法带参数 std::unique_ptrShape createShape(double x, double y, double r) const { return std::make_uniqueParamCircle(x, y, r); } // 也可以重载无参版本提供默认值 std::unique_ptrShape createShape() const override { return std::make_uniqueParamCircle(0, 0, 1.0); // 默认圆心在原点半径为1 } };这里的设计决策在于是将参数作为工厂构造时的配置工厂初始化后参数固定还是作为每次createShape调用时的动态参数。前者适合创建一批参数相同的对象后者则更灵活。需要根据实际场景选择。6. 常见问题、陷阱与排查技巧实录6.1 内存管理问题问题工厂返回原始指针客户端忘记delete导致内存泄漏。排查与解决现象程序运行时间越长内存占用越大在任务管理器或专用工具中观察。解决首选方案如5.1节所述让工厂返回智能指针std::unique_ptr或std::shared_ptr。这是现代C的最佳实践。次选方案如果必须使用原始指针如兼容旧代码务必在文档中明确声明工厂返回的对象所有权转移给了调用者调用者负责删除。可以使用// Caller must take ownership and delete the returned pointer.这样的注释。设计模式结合考虑将工厂模式与对象池Object Pool模式结合工厂管理对象的生命周期客户端只获取和使用对象。6.2 循环依赖与编译问题问题在实现工厂模式时头文件包含关系可能导致循环依赖。排查与解决现象编译报错提示“不完整的类型”、“未定义的类”等。案例ShapeFactory.h需要知道Shape而某个具体产品如Circle的实现文件需要包含其具体工厂CircleFactory.h如果CircleFactory.h又包含了Circle.h就可能产生复杂的依赖。解决前向声明Forward Declaration在头文件中尽可能使用前向声明在源文件中再包含具体的头文件。例如在ShapeFactory.h中只写class Shape;而不包含Shape.h将#include Shape.h移到ShapeFactory.cpp中。这能显著减少编译依赖。依赖倒置确保依赖方向是从高层模块客户端、工厂指向低层模块具体产品而不是反过来。具体产品类不应该依赖具体的工厂类。使用接口隔离确保头文件只包含它必须的内容。如果一个头文件只是声明指针或引用某个类就用前向声明。6.3 扩展时的陷阱问题使用简单工厂模式后增加新产品时需要修改工厂类但修改时引入了错误。排查与解决现象新增产品后编译通过但运行时创建对象失败或创建了错误的对象。解决单元测试为工厂类的createShape方法编写全面的单元测试覆盖所有已知的产品类型并测试传入非法参数的行为。每次修改后运行测试。使用枚举代替字符串在简单工厂中使用字符串作为类型标识容易拼写错误。改用枚举enum class ShapeType { Circle, Rectangle };可以在编译期检查类型更安全。考虑升级到工厂方法模式如果频繁增加新产品这本身就是设计需要改变的信号。应尽早重构为工厂方法模式。6.4 性能考量问题工厂方法模式因为多了虚函数调用和可能的动态内存分配会不会有性能损失排查与解决分析虚函数开销一次虚函数调用通过工厂接口创建产品的开销在现代CPU上通常可以忽略不计除非是在最最核心、每秒调用上亿次的循环中。内存分配开销使用new或std::make_unique进行堆内存分配确实比栈内存分配慢。这是工厂模式尤其是返回对象指针/智能指针时的主要开销来源。优化策略对象池对于创建和销毁频繁的小对象可以使用对象池模式。工厂从池中分配和回收对象避免频繁的堆内存操作。返回栈对象值语义如果产品对象很小且生命周期与作用域一致可以考虑让工厂方法直接返回对象如Shape createShape()但这会涉及对象切片问题必须确保产品类型支持值语义且多态行为不是必须的或者通过CRTP等静态多态实现。这通常与经典工厂模式的应用场景不同。性能测试永远不要盲目优化。先用性能分析工具如perf,VTune,Valgrind定位真正的瓶颈。在绝大多数业务逻辑中工厂模式带来的灵活性收益远大于其微小的性能开销。6.5 设计过度与不足问题在简单场景用了工厂方法模式过度设计或在复杂多变场景用了简单工厂模式设计不足。排查审视需求变化的频率和范围。如果代码几乎从不增加新产品类型那么工厂方法模式增加的抽象层就是负担。如果经常需要增加新产品或者产品创建逻辑复杂多变那么简单工厂很快就会变成维护的噩梦。心法没有最好的模式只有最合适的模式。理解每种模式的代价复杂度和收益灵活性根据项目阶段和预期演化做出权衡。一个实用的技巧是开始时可以用简单工厂快速实现但当发现需要第二次修改工厂类来增加新产品时就应该严肃考虑重构为工厂方法模式了。这种“三次法则”事不过三在软件设计中很常用。
1. 项目概述从“new”的困境到设计模式的优雅解耦在C面向对象编程的旅途中我们迟早会撞上这样一个经典的“泥潭”你的代码里散落着大量的new关键字它们像钉子一样将具体的类名和创建逻辑死死地钉在了业务代码里。想象一下你正在开发一个图形编辑器代码里到处都是new Circle()、new Rectangle()、new Triangle()。今天产品经理说我们要加一个五角星Star你不得不满世界去找那些new的地方小心翼翼地修改。明天又说Circle的构造参数要变你又是一通焦头烂额的查找和替换。这种代码的“坏味道”我们称之为“紧耦合”——创建对象的责任和对象的使用者绑得太死了牵一发而动全身。简单工厂模式和工厂方法模式就是为解决这个“创建之痛”而生的两种经典设计模式。它们不是什么高深莫测的黑魔法而是前辈们在无数个加班夜里从痛苦的重复劳动中提炼出的智慧结晶。简单工厂模式就像一个万能的前台你告诉它你要什么比如“画个圆形”它就去后台帮你把对应的“产品”Circle对象拿出来给你。而工厂方法模式则更进一步它为每一类产品都设立了一个专属的“车间主任”工厂接口由具体的“车间”子类工厂来决定生产什么。今天我们就来亲手用C实现它们看看如何把混乱的new整理成清晰、可扩展的创建流水线。2. 简单工厂模式集中管理的“对象便利店”2.1 模式动机与核心思想简单工厂模式的核心思想非常简单将对象的创建过程封装到一个单独的类中。这个类就像一个中央厨房客户端也就是使用对象的代码不需要知道汉堡、薯条是怎么做出来的它只需要告诉厨房“我要一个汉堡”厨房就会把做好的汉堡递出来。这样做最大的好处是职责分离创建对象的复杂逻辑被隔离了客户端代码变得干净只关心如何使用对象而不关心对象从哪来、怎么来。2.2 经典场景图形绘制系统让我们用一个最直观的例子来切入。假设我们有一个图形绘制系统需要支持多种形状比如圆形、矩形。最原始也是最糟糕的写法可能是这样的// 糟糕的紧耦合示例 void drawShape(const std::string type) { if (type circle) { Circle* circle new Circle(); circle-draw(); delete circle; } else if (type rectangle) { Rectangle* rect new Rectangle(); rect-draw(); delete rect; } // 每增加一种新形状这里就要加一个if分支 }这段代码的问题显而易见drawShape函数承担了太多责任判断类型、创建对象、使用对象并且对Circle、Rectangle这些具体类名产生了直接依赖。简单工厂模式就是来收拾这个烂摊子的。2.3 C实现详解首先我们定义所有图形的抽象基类这是多态的基础。// Shape.h - 抽象产品接口 #ifndef SHAPE_H #define SHAPE_H #include iostream class Shape { public: virtual ~Shape() {} // 虚析构函数确保正确释放子类资源 virtual void draw() const 0; // 纯虚函数定义图形绘制的接口 }; #endif // SHAPE_H接着实现两种具体的图形产品。// Circle.h / Circle.cpp #ifndef CIRCLE_H #define CIRCLE_H #include Shape.h class Circle : public Shape { public: void draw() const override { std::cout Drawing a Circle. std::endl; } }; #endif // CIRCLE_H// Rectangle.h / Rectangle.cpp #ifndef RECTANGLE_H #define RECTANGLE_H #include Shape.h class Rectangle : public Shape { public: void draw() const override { std::cout Drawing a Rectangle. std::endl; } }; #endif // RECTANGLE_H现在重头戏来了——简单工厂类。它的核心是一个静态方法根据传入的参数创建对应的对象。// SimpleShapeFactory.h #ifndef SIMPLE_SHAPE_FACTORY_H #define SIMPLE_SHAPE_FACTORY_H #include Shape.h #include Circle.h #include Rectangle.h #include string #include stdexcept // 用于异常处理 class SimpleShapeFactory { public: // 静态工厂方法根据类型字符串创建对应的Shape对象 static Shape* createShape(const std::string shapeType) { if (shapeType CIRCLE) { return new Circle(); } else if (shapeType RECTANGLE) { return new Rectangle(); } else { // 更好的做法是抛出一个明确的异常而不是返回nullptr throw std::invalid_argument(Unsupported shape type: shapeType); } } }; #endif // SIMPLE_SHAPE_FACTORY_H最后看看客户端代码变得多么清爽// main.cpp #include SimpleShapeFactory.h #include memory // 使用智能指针管理资源 int main() { try { // 客户端只需要知道工厂和产品接口完全不知道Circle、Rectangle的存在 std::unique_ptrShape shape1(SimpleShapeFactory::createShape(CIRCLE)); shape1-draw(); // 输出: Drawing a Circle. std::unique_ptrShape shape2(SimpleShapeFactory::createShape(RECTANGLE)); shape2-draw(); // 输出: Drawing a Rectangle. // 尝试创建不支持的形状会抛出异常 // std::unique_ptrShape shape3(SimpleShapeFactory::createShape(TRIANGLE)); } catch (const std::exception e) { std::cerr Error: e.what() std::endl; } return 0; }注意上面的示例中工厂返回的是原始指针。在现代C中更推荐返回std::unique_ptrShape将资源管理的责任也一并封装进工厂彻底避免内存泄漏。我们可以将createShape的返回值改为std::unique_ptrShape内部使用std::make_unique来创建对象。2.4 模式结构与优缺点分析简单工厂模式的结构非常简单通常包含三个角色工厂类SimpleShapeFactory核心负责创建所有具体产品实例。它拥有一个静态方法或普通方法该方法根据传入的参数如字符串、枚举进行条件判断决定实例化哪个具体类。抽象产品接口Shape定义了产品对象的公共接口所有具体产品都必须实现它。这是客户端依赖的唯一类型。具体产品类Circle, Rectangle实现了抽象产品接口是工厂最终创建的对象。它的优点非常突出职责清晰将对象的创建和使用分离客户端无需关心创建细节。初步解耦客户端只依赖抽象产品Shape和工厂类不依赖具体的Circle、Rectangle降低了系统的耦合度。易于管理所有创建逻辑集中在一处便于统一管理和修改例如引入对象池、单例等。但它的缺点也同样明显这也是它被称为“静态工厂”的原因违反开闭原则这是最致命的缺点。开闭原则要求“对扩展开放对修改关闭”。当我们需要增加一个新的产品比如Triangle时我们必须修改工厂类SimpleShapeFactory中的createShape方法增加一个新的if分支。这违反了“修改关闭”的原则。工厂类职责过重随着产品种类的增加工厂方法会变成一个庞大的if-else或switch语句难以维护。静态方法限制使用静态方法使得工厂类难以继承和扩展无法基于工厂类形成多态。简单工厂模式适用于产品种类相对固定、不太可能频繁增加的系统。它是一个很好的起点但当变化来临时我们就需要更强大的模式——工厂方法模式。3. 工厂方法模式将创建权下放的“多态工厂”3.1 模式动机与核心思想工厂方法模式是对简单工厂模式的深化和抽象。它解决了简单工厂模式的核心痛点——违反开闭原则。工厂方法模式的核心思想是定义一个用于创建对象的接口但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。听起来有点绕用我们之前的比喻来说就是简单工厂是一个万能前台而工厂方法模式则是设立了一个“工厂经理”的岗位接口然后为每种产品招聘一个专门的“车间主任”具体工厂。客户端需要产品时先找到对应的“车间主任”由他来负责生产。这样要增加新产品比如三角形我们不需要修改任何现有工厂的代码只需要新招聘一个“三角形车间主任”即可。3.2 经典场景演进支持多图形与扩展继续我们的图形编辑器。现在需求升级了我们不仅要画平面图形未来还可能画三维图形甚至不同风格的图形如粗线条风格、虚线风格。简单工厂的集中判断逻辑会迅速膨胀到无法维护。工厂方法模式正是为此而生。3.3 C实现详解首先抽象产品接口Shape保持不变。具体产品Circle和Rectangle也保持不变。关键的变化在于工厂。我们不再使用一个具体的工厂类而是定义一个抽象的工厂接口。// ShapeFactory.h - 抽象工厂接口 #ifndef SHAPE_FACTORY_H #define SHAPE_FACTORY_H #include Shape.h class ShapeFactory { public: virtual ~ShapeFactory() {} // 工厂方法由子类实现具体创建逻辑 virtual Shape* createShape() const 0; }; #endif // SHAPE_FACTORY_H接下来为每一种具体的产品创建一个对应的具体工厂类。每个工厂只负责创建一种产品。// CircleFactory.h #ifndef CIRCLE_FACTORY_H #define CIRCLE_FACTORY_H #include ShapeFactory.h #include Circle.h class CircleFactory : public ShapeFactory { public: Shape* createShape() const override { return new Circle(); // 专注于创建Circle对象 } }; #endif // CIRCLE_FACTORY_H// RectangleFactory.h #ifndef RECTANGLE_FACTORY_H #define RECTANGLE_FACTORY_H #include ShapeFactory.h #include Rectangle.h class RectangleFactory : public ShapeFactory { public: Shape* createShape() const override { return new Rectangle(); // 专注于创建Rectangle对象 } }; #endif // RECTANGLE_FACTORY_H现在客户端代码的使用方式发生了变化。它需要先决定使用哪个工厂然后通过工厂接口来创建产品。// main.cpp - 使用工厂方法模式 #include CircleFactory.h #include RectangleFactory.h #include iostream #include memory #include vector void renderScene(const ShapeFactory factory) { // 客户端代码只依赖于抽象工厂和抽象产品 std::unique_ptrShape shape(factory.createShape()); shape-draw(); } int main() { // 创建具体的工厂对象 CircleFactory circleFactory; RectangleFactory rectFactory; std::cout Using Factory Method Pattern: std::endl; renderScene(circleFactory); // 输出: Drawing a Circle. renderScene(rectFactory); // 输出: Drawing a Rectangle. // 动态使用工厂的示例 std::vectorShapeFactory* factories {circleFactory, rectFactory}; for (auto factory : factories) { std::unique_ptrShape shape(factory-createShape()); shape-draw(); } return 0; }现在如果我们需要增加一个Triangle产品应该怎么做创建具体产品类Triangle继承自Shape。创建具体工厂类TriangleFactory继承自ShapeFactory实现createShape()返回new Triangle()。完毕我们没有修改任何现有的CircleFactory、RectangleFactory或ShapeFactory接口。系统完全符合开闭原则。3.4 模式结构与深度解析工厂方法模式包含四个角色抽象产品ProductShape定义产品的接口。具体产品ConcreteProductCircle,Rectangle实现抽象产品接口。抽象工厂CreatorShapeFactory声明工厂方法createShape该方法返回一个抽象产品类型的对象。它可以定义该方法的默认实现返回一个默认产品也可以将其定义为纯虚函数。具体工厂ConcreteCreatorCircleFactory,RectangleFactory重写工厂方法返回一个具体产品的实例。工厂方法模式的优点完全符合开闭原则这是最大的优势。增加新产品时只需添加新的具体产品和具体工厂无需修改现有代码扩展性极佳。多态性客户端代码完全针对抽象工厂和抽象产品编程具体工厂和具体产品的变化被隔离。这使得系统可以在不修改客户端代码的情况下切换或配置不同的产品族。职责进一步细化每个具体工厂只负责创建一种产品符合单一职责原则。工厂方法模式的缺点类的数量爆炸每增加一个产品就需要增加一个具体产品类和一个具体工厂类。在大型系统中这会导致类的数量成倍增加增加系统的复杂度和理解成本。增加了抽象层引入了额外的抽象工厂层对于简单场景来说可能显得有些“过度设计”。3.5 参数化工厂方法一种灵活的变体标准的工厂方法模式是“一个工厂对应一个产品”。但有时我们可能希望一个工厂能根据参数创建不同的产品类似简单工厂同时又保持扩展性。这可以通过在抽象工厂接口中增加参数来实现但需要谨慎设计避免走回简单工厂的老路在方法内写if-else。一种更优雅的方式是结合“注册表”或“映射”。抽象工厂提供一个注册和获取工厂的方法具体工厂在启动时向全局注册表注册自己。客户端通过产品类型键从注册表中获取对应的工厂再创建产品。这样既保持了扩展性又提供了类似简单工厂的便捷调用方式。这通常被视为工厂方法模式与抽象工厂模式或反射机制的结合应用在C中实现起来稍复杂但非常强大。4. 两种模式的对比与选型指南简单工厂模式和工厂方法模式经常被拿来比较理解它们的本质区别是正确选型的关键。特性维度简单工厂模式工厂方法模式核心角色一个具体工厂类包含创建所有产品的静态/普通方法。一个抽象工厂接口和多个具体工厂类每个具体工厂负责一种产品。创建逻辑集中在工厂类的单个方法中通过条件判断if-else/switch决定创建哪种产品。分散在各个具体工厂类中每个工厂类独立实现自己的创建逻辑。扩展方式违反开闭原则。增加新产品必须修改工厂类的源代码。符合开闭原则。增加新产品只需新增具体产品类和具体工厂类无需修改已有代码。客户端依赖依赖具体工厂类。依赖抽象工厂接口和抽象产品接口。类数量少1个工厂类 n个产品类。多n个工厂类 n个产品类 1个抽象工厂接口。适用场景产品种类少且稳定创建逻辑简单不需要频繁扩展。适合作为复杂工厂模式的入门或过渡方案。产品种类多或可能频繁增加系统需要良好的扩展性和灵活性。是许多框架和库如Qt的QStyle中常用的模式。设计原则主要体现了“封装变化”和“单一职责”。完美体现了“开闭原则”、“依赖倒置原则”和“多态”。选型心法如果你能确定产品类型基本固定几年内都不会大变比如一个内部工具只处理有限的几种文件格式那么简单工厂的简洁性更有优势。它用最少的代码解决了核心的耦合问题。如果你在开发一个框架、库或者一个需要长期迭代、功能会不断丰富的应用那么工厂方法模式几乎是必选。它为未来的变化预留了标准的扩展插槽。今天多写几个类是为了明天不用通宵改代码。当创建逻辑本身非常复杂或者需要进行复杂的初始化、配置时即使产品种类不多也值得用一个专门的工厂类可以是简单工厂来封装这比把创建代码散落在客户端各处要好得多。在C中还需要考虑对象所有权的生命周期。无论是简单工厂还是工厂方法返回原始指针在现代C中都已不推荐。更佳实践是让工厂方法返回std::unique_ptrProduct将资源管理的责任也封装起来。如果需要有共享所有权的场景则可以返回std::shared_ptrProduct。5. 实战进阶结合现代C特性的优雅实现5.1 使用智能指针管理资源原始指针管理内存容易出错。让我们用std::unique_ptr改造我们的工厂方法模式这是现代C的标配。// ShapeFactory.h (Modern) #ifndef SHAPE_FACTORY_MODERN_H #define SHAPE_FACTORY_MODERN_H #include memory #include Shape.h class ShapeFactory { public: virtual ~ShapeFactory() default; // 工厂方法返回unique_ptr明确所有权转移给调用者 virtual std::unique_ptrShape createShape() const 0; }; #endif // SHAPE_FACTORY_MODERN_H// CircleFactory.cpp (Modern) #include CircleFactory.h #include memory std::unique_ptrShape CircleFactory::createShape() const { // 使用std::make_unique进行创建C14及以上 return std::make_uniqueCircle(); }客户端使用起来也更安全// 客户端代码 CircleFactory cf; auto shape cf.createShape(); // shape是std::unique_ptrShape shape-draw(); // 无需手动deleteshape离开作用域自动释放内存5.2 使用函数对象或Lambda作为轻量级工厂对于极其简单的创建逻辑有时我们不想为每个产品都定义一个完整的工厂类。C的函数对象仿函数或Lambda表达式可以作为一种轻量级的工厂。// 使用函数对象作为工厂 class ShapeCreator { public: virtual ~ShapeCreator() default; virtual std::unique_ptrShape operator()() const 0; }; class CreateCircle : public ShapeCreator { public: std::unique_ptrShape operator()() const override { return std::make_uniqueCircle(); } }; // 使用Lambda和std::function存储工厂逻辑 using ShapeFactoryFunc std::functionstd::unique_ptrShape(); std::mapstd::string, ShapeFactoryFunc factoryRegistry; factoryRegistry[circle] []() { return std::make_uniqueCircle(); }; factoryRegistry[rectangle] []() { return std::make_uniqueRectangle(); }; auto shape factoryRegistry[circle](); // 创建圆形这种方式非常灵活特别适合与配置系统结合动态注册和创建对象。5.3 处理对象构造参数工厂模式的一个常见需求是产品构造时需要参数。我们的工厂方法需要能够传递这些参数。// 带参数的Shape例如圆心和半径 class ParamCircle : public Shape { public: ParamCircle(double x, double y, double r) : centerX(x), centerY(y), radius(r) {} void draw() const override { /* ... */ } private: double centerX, centerY, radius; }; // 对应的工厂也需要支持参数 class ParamCircleFactory : public ShapeFactory { public: // 工厂方法带参数 std::unique_ptrShape createShape(double x, double y, double r) const { return std::make_uniqueParamCircle(x, y, r); } // 也可以重载无参版本提供默认值 std::unique_ptrShape createShape() const override { return std::make_uniqueParamCircle(0, 0, 1.0); // 默认圆心在原点半径为1 } };这里的设计决策在于是将参数作为工厂构造时的配置工厂初始化后参数固定还是作为每次createShape调用时的动态参数。前者适合创建一批参数相同的对象后者则更灵活。需要根据实际场景选择。6. 常见问题、陷阱与排查技巧实录6.1 内存管理问题问题工厂返回原始指针客户端忘记delete导致内存泄漏。排查与解决现象程序运行时间越长内存占用越大在任务管理器或专用工具中观察。解决首选方案如5.1节所述让工厂返回智能指针std::unique_ptr或std::shared_ptr。这是现代C的最佳实践。次选方案如果必须使用原始指针如兼容旧代码务必在文档中明确声明工厂返回的对象所有权转移给了调用者调用者负责删除。可以使用// Caller must take ownership and delete the returned pointer.这样的注释。设计模式结合考虑将工厂模式与对象池Object Pool模式结合工厂管理对象的生命周期客户端只获取和使用对象。6.2 循环依赖与编译问题问题在实现工厂模式时头文件包含关系可能导致循环依赖。排查与解决现象编译报错提示“不完整的类型”、“未定义的类”等。案例ShapeFactory.h需要知道Shape而某个具体产品如Circle的实现文件需要包含其具体工厂CircleFactory.h如果CircleFactory.h又包含了Circle.h就可能产生复杂的依赖。解决前向声明Forward Declaration在头文件中尽可能使用前向声明在源文件中再包含具体的头文件。例如在ShapeFactory.h中只写class Shape;而不包含Shape.h将#include Shape.h移到ShapeFactory.cpp中。这能显著减少编译依赖。依赖倒置确保依赖方向是从高层模块客户端、工厂指向低层模块具体产品而不是反过来。具体产品类不应该依赖具体的工厂类。使用接口隔离确保头文件只包含它必须的内容。如果一个头文件只是声明指针或引用某个类就用前向声明。6.3 扩展时的陷阱问题使用简单工厂模式后增加新产品时需要修改工厂类但修改时引入了错误。排查与解决现象新增产品后编译通过但运行时创建对象失败或创建了错误的对象。解决单元测试为工厂类的createShape方法编写全面的单元测试覆盖所有已知的产品类型并测试传入非法参数的行为。每次修改后运行测试。使用枚举代替字符串在简单工厂中使用字符串作为类型标识容易拼写错误。改用枚举enum class ShapeType { Circle, Rectangle };可以在编译期检查类型更安全。考虑升级到工厂方法模式如果频繁增加新产品这本身就是设计需要改变的信号。应尽早重构为工厂方法模式。6.4 性能考量问题工厂方法模式因为多了虚函数调用和可能的动态内存分配会不会有性能损失排查与解决分析虚函数开销一次虚函数调用通过工厂接口创建产品的开销在现代CPU上通常可以忽略不计除非是在最最核心、每秒调用上亿次的循环中。内存分配开销使用new或std::make_unique进行堆内存分配确实比栈内存分配慢。这是工厂模式尤其是返回对象指针/智能指针时的主要开销来源。优化策略对象池对于创建和销毁频繁的小对象可以使用对象池模式。工厂从池中分配和回收对象避免频繁的堆内存操作。返回栈对象值语义如果产品对象很小且生命周期与作用域一致可以考虑让工厂方法直接返回对象如Shape createShape()但这会涉及对象切片问题必须确保产品类型支持值语义且多态行为不是必须的或者通过CRTP等静态多态实现。这通常与经典工厂模式的应用场景不同。性能测试永远不要盲目优化。先用性能分析工具如perf,VTune,Valgrind定位真正的瓶颈。在绝大多数业务逻辑中工厂模式带来的灵活性收益远大于其微小的性能开销。6.5 设计过度与不足问题在简单场景用了工厂方法模式过度设计或在复杂多变场景用了简单工厂模式设计不足。排查审视需求变化的频率和范围。如果代码几乎从不增加新产品类型那么工厂方法模式增加的抽象层就是负担。如果经常需要增加新产品或者产品创建逻辑复杂多变那么简单工厂很快就会变成维护的噩梦。心法没有最好的模式只有最合适的模式。理解每种模式的代价复杂度和收益灵活性根据项目阶段和预期演化做出权衡。一个实用的技巧是开始时可以用简单工厂快速实现但当发现需要第二次修改工厂类来增加新产品时就应该严肃考虑重构为工厂方法模式了。这种“三次法则”事不过三在软件设计中很常用。
