1. 从“new Object()”到设计模式为什么我们需要对象创建模式在JavaScript的世界里对象是我们打交道最多的实体。从初学时的let obj {}或new Object()到后来用构造函数function Person(name) { this.name name; }我们似乎已经掌握了创建对象的所有方法。但随着项目规模扩大代码复杂度提升你会发现事情没那么简单。当你需要根据不同的配置创建一系列相似但又不完全相同的对象时当你发现new关键字和构造函数让你的代码难以测试、难以扩展时当你面对一个需要灵活组装、内部状态复杂的对象时原始的创建方式就显得力不从心了。这就是对象创建模式要解决的问题。它不是一个具体的语法而是一套经过实践检验的、用于优化对象创建过程的设计思想和代码组织方式。简单来说它关乎“如何更优雅、更灵活、更安全地把一个对象‘造’出来”。理解这些模式意味着你从“会用JavaScript写对象”进阶到了“懂得如何设计对象的诞生过程”这对于构建可维护、可复用的大型应用至关重要。今天我们就来深入拆解JavaScript中几种核心的对象创建模式从最基础的工厂模式到经典的构造器模式、原型模式再到更高级的组合模式看看它们各自解决了什么问题以及在实际编码中如何选择和运用。2. 构造器模式经典背后的隐患与“new”的魔法构造器模式是我们最熟悉的对象创建方式。它看起来直白又强大定义一个函数用new关键字调用一个新对象就诞生了。function Car(model, year) { this.model model; this.year year; this.toString function() { return ${this.model} (${this.year}); }; } const myCar new Car(Toyota, 2020); console.log(myCar.toString()); // Toyota (2020)2.1 “new”到底做了什么很多开发者只是机械地使用new却不清楚背后的四步魔法创建一个全新的空对象。将这个新对象的[[Prototype]]即__proto__链接到构造函数的prototype对象。这是实现继承的关键。将构造函数内部的this绑定到这个新创建的对象并执行构造函数内部的代码为这个新对象添加属性。如果构造函数没有显式返回一个对象则自动返回这个新创建的对象。理解这个过程就能明白为什么在构造函数里直接给this赋值会生效也就能避免一些常见的错误比如忘记写new导致this指向全局对象在非严格模式下。2.2 构造器模式的明显缺陷尽管经典但上面的例子暴露了构造器模式一个严重的性能问题方法重复创建。例子中toString方法是定义在构造函数内部的这意味着每次调用new Car()都会创建一个全新的函数对象赋值给this.toString。如果有1000个Car实例就会有1000个功能完全相同的toString函数在内存中这无疑是巨大的浪费。const car1 new Car(A, 2020); const car2 new Car(B, 2021); console.log(car1.toString car2.toString); // false两个不同的函数对象这个缺陷是推动我们寻找更好模式的主要动力之一。我们需要一种方式让所有实例共享相同的方法而不是各自拥有一份拷贝。3. 原型模式共享的力量与属性屏蔽的陷阱为了解决构造器模式的方法重复问题JavaScript 的原型链机制提供了完美的解决方案由此引出了原型模式。其核心思想是将属性和方法定义在构造函数的prototype对象上这样所有实例都能共享这些属性和方法。3.1 原型模式的基本实现function Car(model, year) { // 实例属性每个对象独有 this.model model; this.year year; } // 共享方法定义在原型上 Car.prototype.toString function() { return ${this.model} (${this.year}); }; Car.prototype.drive function() { console.log(${this.model} is driving.); }; const myCar1 new Car(Toyota, 2020); const myCar2 new Car(Honda, 2021); console.log(myCar1.toString myCar2.toString); // true共享同一个函数 myCar1.drive(); // Toyota is driving.现在无论创建多少个Car实例toString和drive方法在内存中都只有一份。实例通过内部的[[Prototype]]链可通过__proto__或Object.getPrototypeOf()访问查找到这些方法。这是JavaScript实现继承和共享行为的基石。3.2 深入理解原型链查找与属性屏蔽原型模式并非没有坑最大的坑在于“属性屏蔽”。看下面的例子function Car() {} Car.prototype.wheels 4; const myCar new Car(); console.log(myCar.wheels); // 4从原型上找到 myCar.wheels 6; // 在实例自身添加同名属性 console.log(myCar.wheels); // 6访问的是自身属性 console.log(Object.getPrototypeOf(myCar).wheels); // 4原型上的值没变 delete myCar.wheels; // 删除自身属性 console.log(myCar.wheels); // 4屏蔽解除再次从原型找到这个过程揭示了原型链的属性访问规则当试图访问一个对象的属性时引擎首先在对象自身查找。如果没找到则沿着对象的[[Prototype]]链向上查找。如果最终在原型链上找到则返回该值。如果给对象赋值一个原型链上也存在的属性名不会修改原型上的属性而是在对象自身创建或修改这个属性从而“屏蔽”了原型上的属性。 注意这是一个非常关键且容易出错的概念。在大型项目中如果不清楚这个规则可能会意外地修改了某个实例的属性却困惑于为什么其他实例的行为没有改变。始终记住直接通过实例赋值影响的是该实例自身要修改原型上的属性必须通过Constructor.prototype.property来操作。3.3 原型模式的局限性原型模式完美解决了方法的共享问题但它通常与构造器模式结合使用如上例因为纯原型模式在处理需要独立初始化的实例属性时很不方便。纯原型模式意味着所有属性都在原型上定义这会导致所有实例共享相同的属性值这显然不是我们想要的function BadCar() {} BadCar.prototype.model Default; // 所有实例共享 BadCar.prototype.year 2000; const car1 new BadCar(); const car2 new BadCar(); car1.model Toyota; // 这会在car1自身上创建model属性但car2.model还是Default逻辑混乱。因此在实践中组合使用构造器模式和原型模式成为了最主流、最推荐的模式构造器用于定义实例属性原型用于定义共享方法和常量属性。4. 动态原型模式更优雅的封装组合构造器与原型模式虽然好用但有一个小瑕疵代码的组织是分离的。构造函数的定义在一处原型方法的添加在另一处。这破坏了代码的封装性和可读性尤其是当类的方法很多时你需要滚动屏幕在构造函数和原型赋值代码块之间来回跳转。动态原型模式提供了一种更优雅的封装方式将原型方法的定义也封装在构造函数内部并且通过判断确保只初始化一次。function Car(model, year) { // 实例属性 this.model model; this.year year; // 方法动态添加到原型仅第一次调用构造函数时执行 if (typeof Car.prototype.drive ! function) { Car.prototype.drive function() { console.log(${this.model} is driving.); }; Car.prototype.toString function() { return ${this.model} (${this.year}); }; // 可以继续添加其他方法... } } const car1 new Car(Toyota, 2020); const car2 new Car(Honda, 2021); console.log(car1.drive car2.drive); // true共享方法 car1.drive(); // Toyota is driving.这里的技巧在于if判断。当第一次调用new Car()时Car.prototype.drive是undefined条件为真执行花括号内的代码将方法添加到原型上。之后再次调用new Car()原型上已经存在drive方法条件为假跳过初始化避免了重复赋值。 提示动态原型模式是我个人非常偏爱的一种风格。它让一个“类”的所有定义属性初始化、方法声明都集中在一个函数块内代码结构更紧凑维护起来更方便。你只需要查看构造函数内部就能对这个类的全貌有一个清晰的了解。这对于阅读代码的人来说非常友好。5. 寄生构造模式与稳妥构造模式特殊场景的解决方案除了上述主流模式还有两种在特定场景下有用的模式。5.1 寄生构造模式这种模式的基本思想是创建一个函数这个函数封装了创建对象的代码类似于工厂函数但最后使用new关键字来调用并返回这个新创建的对象。它通常用于扩展一个已有类型但又不想直接修改其原型。一个经典的例子是你想创建一个具有额外方法的特殊数组function SpecialArray() { // 创建数组对象 const values new Array(); // 添加初始值arguments是传入的参数 values.push.apply(values, arguments); // 添加自定义方法 values.toPipedString function() { return this.join(|); }; // 返回这个加工过的对象 return values; } const colors new SpecialArray(red, blue, green); console.log(colors.toPipedString()); // red|blue|green console.log(colors instanceof SpecialArray); // false console.log(colors instanceof Array); // true注意colors并不是SpecialArray的实例而是Array的实例。因为new操作符在遇到构造函数返回一个对象时会直接返回这个对象而不是默认创建的那个this。寄生构造模式让你能利用new的语法但返回一个完全不同的、经过“寄生”增强的对象。5.2 稳妥构造模式稳妥构造模式由道格拉斯·克罗克福德提出主要目的是创建没有公共属性且其方法不引用this的“稳妥对象”。这种对象非常适合在一些安全环境如防止数据被篡改或某些框架中使用。function Person(name, age, job) { // 创建要返回的对象 const o new Object(); // 可以在这里定义私有变量和函数 const secretCode 123456; // 定义公共方法特权方法这些方法可以访问私有变量 o.sayName function() { // 注意这里不直接暴露name而是通过闭包访问 console.log(name); // 访问的是构造函数作用域中的name参数 }; o.getSecret function() { return secretCode; }; // 返回对象 return o; } const friend Person(Nicholas, 29, Software Engineer); friend.sayName(); // Nicholas console.log(friend.name); // undefined无法直接访问 console.log(friend.getSecret()); // 123456稳妥构造模式的特点不使用new操作符调用构造函数。不引用this。在方法中通过闭包访问传入的原始数据。这样创建的对象其内部状态对于外部是完全隐藏的只能通过暴露的特定方法sayName,getSecret来交互。这提供了很好的封装性和安全性。当然它的缺点也很明显每个方法都是独立的函数无法在实例间共享会占用更多内存。因此它通常只在有特定安全或封装需求时使用。6. 工厂模式与抽象工厂解耦创建逻辑当我们把视线从“如何定义一个对象的模板”转移到“如何管理对象的创建过程”时工厂模式就登场了。它的核心目标是将对象的创建逻辑封装起来调用者无需关心具体的创建细节。6.1 简单工厂模式这就像一个“对象创建中心”。你告诉工厂你需要什么类型的产品工厂负责把产品造出来给你。// 产品类型 function Car(options) { this.model options.model; this.year options.year; } function Truck(options) { this.capacity options.capacity; } // 工厂 function VehicleFactory() {} VehicleFactory.prototype.createVehicle function(options) { switch(options.vehicleType) { case car: return new Car(options); case truck: return new Truck(options); default: throw new Error(Unsupported vehicle type); } }; // 使用工厂 const factory new VehicleFactory(); const myCar factory.createVehicle({ vehicleType: car, model: Toyota, year: 2020 }); const myTruck factory.createVehicle({ vehicleType: truck, capacity: 5吨 });好处调用者客户端代码只需要知道VehicleFactory和createVehicle方法完全不用关心Car和Truck的具体构造函数是什么、如何初始化。如果未来要新增一个Motorcycle类型只需要修改工厂内部的switch语句客户端代码几乎不用动。这符合“开闭原则”对扩展开放对修改关闭。6.2 抽象工厂模式简单工厂在类型不多时很好用但当产品家族变得庞大比如有不同品牌的汽车、不同品牌的卡车时switch会变得臃肿。抽象工厂模式提供了一个更结构化的解决方案它为创建一系列相关或依赖的对象提供一个接口而无需指定它们具体的类。假设我们有两个UI主题亮色Light和暗色Dark。每个主题都包含按钮Button和对话框Dialog。// 抽象产品类定义产品接口 class Button { render() { throw new Error(You have to implement the method render!); } } class Dialog { render() { throw new Error(You have to implement the method render!); } } // 具体产品Light主题 class LightButton extends Button { render() { console.log(Rendering a light-themed button.); } } class LightDialog extends Dialog { render() { console.log(Rendering a light-themed dialog.); } } // 具体产品Dark主题 class DarkButton extends Button { render() { console.log(Rendering a dark-themed button.); } } class DarkDialog extends Dialog { render() { console.log(Rendering a dark-themed dialog.); } } // 抽象工厂定义创建产品家族的接口 class UIFactory { createButton() { throw new Error(You have to implement the method createButton!); } createDialog() { throw new Error(You have to implement the method createDialog!); } } // 具体工厂创建Light主题产品家族 class LightUIFactory extends UIFactory { createButton() { return new LightButton(); } createDialog() { return new LightDialog(); } } // 具体工厂创建Dark主题产品家族 class DarkUIFactory extends UIFactory { createButton() { return new DarkButton(); } createDialog() { return new DarkDialog(); } } // 客户端代码 function application(factory) { const button factory.createButton(); const dialog factory.createDialog(); button.render(); dialog.render(); } // 根据配置使用不同的工厂 const config { theme: dark }; let factory; if (config.theme light) { factory new LightUIFactory(); } else { factory new DarkUIFactory(); } application(factory); // 输出: Rendering a dark-themed button. / Rendering a dark-themed dialog.抽象工厂的价值客户端代码application函数只依赖于抽象的UIFactory、Button和Dialog。它完全不知道具体创建的是LightButton还是DarkButton。切换整个产品家族主题变得异常简单只需要更换一个具体的工厂实例即可。这极大地降低了系统各部分之间的耦合度使得替换一整套UI组件变得轻而易举。 实操心得工厂模式特别是抽象工厂在大型前端框架和复杂业务系统中非常常见。例如一个图表库可能有一个ChartFactory根据传入的type: line或bar返回不同的图表实例。而抽象工厂则常用于设计系统Design System中确保同一套设计语言下的所有组件按钮、输入框、卡片风格一致。当你发现代码中有很多new关键字并且这些new分散在各处逻辑复杂时就该考虑引入工厂模式来集中管理创建逻辑了。7. 建造者模式分步构建复杂对象有些对象非常复杂拥有众多部件和复杂的装配过程。用一个庞大的构造函数接收几十个参数来初始化不仅难以阅读而且容易出错参数顺序错了怎么办。建造者模式就是为了解决这个问题而生它将一个复杂对象的构建与它的表示分离使得同样的构建过程可以创建不同的表示。想象一下你要创建一个HttpRequest对象它需要配置URL、方法、头部、超时时间、请求体等等。糟糕的做法巨型构造函数const request new HttpRequest(https://api.example.com, POST, { Content-Type: application/json }, 5000, JSON.stringify({ data: test })); // 哪个参数对应什么完全记不住。建造者模式的做法class HttpRequest { constructor() { this.url ; this.method GET; this.headers {}; this.timeout 0; this.body null; } } class HttpRequestBuilder { constructor() { this.request new HttpRequest(); } setUrl(url) { this.request.url url; return this; // 关键返回this支持链式调用 } setMethod(method) { this.request.method method; return this; } setHeader(key, value) { this.request.headers[key] value; return this; } setTimeout(timeout) { this.request.timeout timeout; return this; } setBody(body) { this.request.body body; return this; } build() { // 这里可以进行最终的校验 if (!this.request.url) { throw new Error(URL is required.); } return this.request; } } // 使用建造者 const request new HttpRequestBuilder() .setUrl(https://api.example.com/data) .setMethod(POST) .setHeader(Content-Type, application/json) .setTimeout(5000) .setBody(JSON.stringify({ data: test })) .build(); // 最终构建出对象 console.log(request);建造者模式的优势良好的封装性建造过程被封装在Builder类中客户端无需知道对象内部的组成细节。易于扩展要增加新的构建步骤或参数只需要在Builder中添加新的方法即可符合开闭原则。更好的控制构建过程可以在build()方法中进行最终校验确保构建出的对象是有效的。链式调用代码清晰通过返回this实现链式调用代码读起来就像在描述构建步骤非常直观。 注意事项建造者模式适用于创建那些包含多个组成部分、且构建顺序可能灵活变化的复杂对象。对于简单的对象使用建造者模式反而会引入不必要的复杂度。在JavaScript中我们也可以利用“参数对象”来简化构造函数这可以看作是一种轻量级的建造者模式变体。例如new HttpRequest({ url: ..., method: POST, headers: {...} })。但当构建逻辑非常复杂需要分步、有条件地构建时完整的建造者模式依然是更好的选择。8. 单例模式确保全局唯一实例单例模式可能是最广为人知的设计模式之一。它的意图是保证一个类仅有一个实例并提供一个访问它的全局访问点。在前端开发中单例模式的应用场景非常多例如全局状态管理如Redux Store、模态框Modal管理器、浏览器环境下的全局对象如window、document本身就是单例、日志记录器、配置管理器等。8.1 传统的单例实现基于类在ES6之前我们通常使用闭包或者立即执行函数来实现单例。// 使用闭包和立即执行函数 const Singleton (function() { let instance; // 闭包内保存唯一实例 function createInstance() { // 这里是实际的构造函数逻辑 const object new Object(I am the instance); return object; } return { getInstance: function() { if (!instance) { instance createInstance(); } return instance; } }; })(); // 使用 const instance1 Singleton.getInstance(); const instance2 Singleton.getInstance(); console.log(instance1 instance2); // true8.2 ES6 时代的单例实现有了ES6的类和模块系统实现单例变得更加简洁。一个非常巧妙且常用的方法是利用ES6模块的天然单例特性。// Logger.js (一个模块文件) class Logger { constructor() { this.logs []; if (Logger.instance) { return Logger.instance; // 如果已存在实例直接返回 } Logger.instance this; // 否则将当前实例赋值给静态属性 return this; } log(message) { this.logs.push(message); console.log(LOG: ${message}); } printLogCount() { console.log(Number of logs: ${this.logs.length}); } } // 关键立即创建并导出一个实例 const instance new Logger(); Object.freeze(instance); // 可选冻结实例防止被修改 export default instance;// app.js (使用方) import logger from ./Logger.js; logger.log(First message); logger.log(Second message); logger.printLogCount(); // Number of logs: 2 // 无论你在多少个文件中 import ./Logger.js你得到的都是同一个 logger 实例。8.3 单例模式的陷阱与思考单例模式虽然好用但需要谨慎使用因为它本质上是一个全局变量。过度使用单例会导致一些问题隐藏的耦合单例使代码的依赖关系变得不透明一个模块可能默默地依赖了一个全局单例这不利于单元测试因为难以模拟和代码理解。不利于测试由于单例状态是全局共享的一个测试用例对它的修改可能会影响另一个测试用例导致测试结果不可预测。通常需要额外的reset或mock机制。违反单一职责原则单例类同时承担了“保证唯一性”和“业务逻辑”两种职责。 经验之谈在现代前端开发中对于真正的全局唯一服务如与后端API通信的客户端、应用配置使用单例模式是合理的。但对于那些只是“在当前上下文中需要唯一”的对象考虑使用依赖注入Dependency Injection容器来管理生命周期这能提供更好的灵活性和可测试性。例如在React中你可以使用Context API来提供一个“单例”似的服务给组件树而不是创建一个真正的全局模块单例。这限定了服务的作用范围更加可控。