登录
首页 >  文章 >  java教程

简单工厂模式:面向对象创建对象方法

时间:2026-03-30 23:12:15 414浏览 收藏

简单工厂模式通过将对象创建逻辑集中封装为纯函数,让调用方只需声明“要什么”,无需关心“怎么造”,从而有效规避硬编码散落、多处修改、空值崩溃等常见陷阱;它强调明确抛出异常而非返回 null、拒绝无意义的 class 封装、只服务于有业务含义的对象创建,并警惕自身成为隐式依赖——本质上,它不是炫技的中间层,而是面向变化时让代码更易读、易改、易测的务实选择。

简单工厂模式 (Factory)_使用面向对象思维创建对象

为什么 new 之后还要再包一层工厂函数

直接 new 类没问题,但一旦构造逻辑变复杂(比如要根据配置选不同子类、要预设默认参数、要统一初始化流程),硬编码就容易散落在各处。工厂函数本质是把“怎么造对象”这个决策收口——不是为了炫技,而是让调用方只关心“我要什么”,不操心“怎么造”。

常见错误现象:if-else 判断塞在业务代码里,新增一种类型就得改多处;或者所有地方都写 new ConcreteA(),结果某天 ConcreteA 需要加参数,全项目搜着改。

  • 使用场景:对象创建依赖外部配置(如读取 JSON 决定实例化哪个类)、需要隐藏具体实现类名、构造过程含副作用(如注册监听、加载资源)
  • 参数差异:工厂函数通常接收一个标识符(如字符串 type 或配置对象),而不是原始构造参数;真正传给构造器的参数应由工厂内部处理或透传
  • 性能影响极小,但要注意别在工厂里做重操作(如同步读文件、网络请求),否则每次 create() 都卡

Factory.create() 返回 null 还是抛异常

返回 null 是最危险的默认选择——调用方很容易忘记判空,接着就 Cannot read property 'xxx' of null。简单工厂不该替调用方做“容错”,它该明确表达“你问了个不存在的东西”。

典型错误:工厂里写 if (type === 'A') return new A(); else return null;,然后业务层直接 factory.create('B').doSomething(),运行时报错才回头找。

  • 建议统一抛 Error,消息里带具体 type 和可用选项,比如 throw new Error(`Unknown type: ${type}. Available: A, B, C`)
  • 如果确实需要“可选创建”,那就显式命名,比如 tryCreate(),并文档注明可能返回 nullundefined
  • TypeScript 用户注意:返回类型别写成 MyClass | null,除非真有合法的 null 场景;更推荐用联合类型 + 明确枚举值约束输入

JavaScript 里要不要用 class 实现 Factory

不用。简单工厂的核心是函数,不是类。写成 class Factory { static create() { ... } } 纯属画蛇添足——没有实例状态、不需继承、不靠 this 绑定,加个 class 只会让调用多敲两个点:Factory.create() 对比 create(),还容易让人误以为能 new 出来个工厂实例。

容易踩的坑:有人把工厂做成单例类,然后在构造器里初始化一堆缓存或连接,结果发现根本没被复用,因为每次都是 new Factory().create(),缓存形同虚设。

  • 直接导出纯函数,例如 export function createService(type, options)
  • 如果真需要封装状态(如共享缓存、配置上下文),用闭包或依赖注入,而不是靠 class 包一层
  • Node.js 环境下注意模块缓存:函数导出后多次 require 拿到的是同一个函数引用,闭包变量天然复用

和依赖注入容器(如 InversifyJS)有什么区别

简单工厂就是手动写的、硬编码的、无反射能力的依赖注入。它不扫描类装饰器、不解析构造函数参数、不管理生命周期。当你还没到需要自动装配几十个服务的程度,或者项目是纯前端小工具,上 DI 容器反而增加心智负担和打包体积。

真实冲突点常出现在团队协作中:有人坚持“所有 new 都得走工厂”,结果连 new Date()new Map() 都包一层 DateFactory.create(),完全背离初衷。

  • 工厂只管“有业务含义的对象”,比如 PaymentProcessorNotificationChannel;基础类型、数据结构、纯工具类别裹
  • DI 容器适合大型应用,且要求严格约定(如接口抽象、装饰器标记);简单工厂适合快速验证、脚本、CLI 工具等轻量场景
  • 两者不互斥:可以用工厂作为 DI 容器的“自定义 provider”,但别把工厂当容器用

最常被忽略的一点:工厂函数本身也是依赖。它不该自己读配置、连数据库——这些应该通过参数传入,否则测试时无法 mock,上线后也难切换环境行为。

好了,本文到此结束,带大家了解了《简单工厂模式:面向对象创建对象方法》,希望本文对你有所帮助!关注golang学习网公众号,给大家分享更多文章知识!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>