一、单例模式
1. 概念及原理
单例模式旨在保证在整个应用运行期间，某个类只会有一个实例存在，并且提供一个统一的途径来获取该实例，方便在不同的代码模块中进行访问。在前端开发中，有诸多场景适合运用单例模式，特别是那些涉及全局唯一数据或功能模块的情况。
例如，前端应用往往需要配置一些通用的基础信息，像 API 接口的基础 URL、用于身份验证的密钥等，这些信息在各个组件或者业务模块中都会被用到。如果每个模块都各自创建一份这样的配置对象，不仅会造成内存资源的浪费，还可能导致数据不一致等问题。而单例模式就能很好地解决这个问题，它将这些配置信息集中管理在一个唯一的实例中，供整个应用共享使用。
从实现的角度来看，通常会利用一些机制来确保实例的唯一性。常见的做法是借助闭包，通过一个立即执行函数表达式（IIFE）创建一个封闭的环境，在这个环境里用一个变量来保存实例对象。一开始这个变量为空，当外部首次尝试获取实例时，会执行创建实例的逻辑，后续再次获取时，就直接返回之前已经创建好的那个实例了，以此保证整个应用获取到的都是同一个配置实例。
下面是一个简单的代码示例示意（实际应用场景会更复杂且需要考虑更多的异常处理等情况）：
const GlobalConfig = (function () {
let instance;
function createInstance() {
return {
baseUrl: 'https://example.com',
apiKey: '123456'
};
}
return {
getInstance: function () {
if (!instance) {
instance = createInstance();
}
return instance;
}
};
})();
const config1 = GlobalConfig.getInstance();
const config2 = GlobalConfig.getInstance();
console.log(config1 === config2); // true，说明获取的是同一个实例
2. 优点
- 节省内存资源：在前端项目里，若没有单例模式的约束，对于那些多处使用且功能相同的对象，很容易被重复创建。比如多个页面模块都依赖相同的配置信息，若各自创建配置对象，就会使内存中存在多份相同的数据，无疑增加了内存开销。而单例模式通过确保只有一个实例，有效避免了这种不必要的内存浪费，让内存资源得到更合理的利用。
- 提供便捷的全局访问机制：借助单例模式所设立的全局访问点，无论在应用的哪个部分，是何种组件或者业务模块，都能方便地获取到这个唯一的实例，进而从中获取所需的数据或者调用相关的方法。这使得整个应用在数据共享和交互方面更加有序、高效，不同模块之间能基于这个统一的实例进行协作，减少了数据传递和获取的复杂性。
3. 缺点
- 易违背单一职责原则：随着前端应用功能的不断拓展，单例对象往往容易承载过多的职责。因为它是全局唯一的，开发人员可能会不自觉地往里面添加各种各样与业务相关的属性和方法，导致这个原本应当职责明确、相对简单的对象变得臃肿复杂。例如，最初它可能只是单纯负责管理配置信息，但后续为了满足业务需求，又陆续加入了一些和业务逻辑相关的状态变化处理、数据缓存等功能，使得其代码逻辑混杂，维护和理解起来愈发困难。
- 对单元测试带来挑战：在进行单元测试时，单例模式的全局唯一性会给测试工作带来一定阻碍。由于其只能有一个实例存在，很难模拟出不同的实例状态来分别对依赖它的各个模块进行独立、全面的测试。这就可能使得测试结果不能准确反映出各个模块真实的功能情况，影响对代码质量的评估和问题的排查。
4. 使用案例
在前端项目中，主题配置管理是单例模式的一个典型应用场景。整个应用的颜色主题、字体样式等配置信息通常采用单例模式来存储和管理。各个组件，比如导航栏、按钮组件、文本显示区域等，都可以获取这个单例的主题配置对象来确保外观展示的一致性。当用户选择切换主题时，只需要在这个单例主题配置对象中修改相应的属性值，所有依赖该主题的组件就能自动更新显示效果，实现了整个应用主题风格的统一管理和便捷切换，极大地提升了用户体验，同时也便于开发人员对主题相关的功能进行维护和扩展。
二、观察者模式
1. 概念及原理
观察者模式构建了一种一对多的依赖关系架构，它主要包含两个核心角色：被观察的对象（通常称为主题）以及依赖于该主题的多个对象（即观察者）。其核心机制在于，当主题的状态发生改变时，会主动通知所有与之关联的观察者，而观察者们接收到通知后，会自动执行相应的更新操作，以保证自身状态与主题状态保持同步。
这种模式在前端开发中有着广泛且直观的体现，最为常见的就是 DOM 元素的事件绑定机制。以一个网页中的按钮为例，按钮在这里就相当于主题，而我们给按钮添加的各种点击事件监听器所对应的代码逻辑，就是观察者。当用户点击按钮这个动作发生时（也就是主题的状态发生了改变），绑定的那些点击事件监听器（观察者）就会被触发，进而执行相应的操作，比如弹出提示框、提交表单或者跳转到其他页面等。
从代码层面简单模拟一个自定义事件的观察者模式示例如下（实际应用场景中会在此基础上增加更多功能，比如更灵活的事件注册与移除机制、携带更多详细的通知数据等）：
class Subject {
constructor() {
this.observers = [];
}
addObserver(observer) {
this.observers.push(observer);
}
removeObserver(observer) {
const index = this.observers.indexOf(observer);
if (index!== -1) {
this.observers.splice(index, 1);
}
}
notify(data) {
this.observers.forEach(observer => observer.update(data));
}
}
class Observer {
update(data) {
console.log('收到更新通知，数据为：', data);
}
}
const subject = new Subject();
const observer1 = new Observer();
const observer2 = new Observer();
subject.addObserver(observer1);
subject.addObserver(observer2);
subject.notify('新消息');
2. 优点
- 实现高度的解耦性：观察者模式最大的优势之一就是主题和观察者之间形成了松耦合的关系。主题无需知晓具体有哪些观察者在关注它，只需要专注于自身状态的变化，并在变化发生时发布通知即可。而观察者这边，也不用关心主题内部的状态是如何改变的，只需要按照事先约定好的规则，实现自己的更新方法，以便在收到通知时能够做出恰当的响应。这种解耦的设计使得各个模块的职责更加清晰，代码的可维护性和扩展性都得到了显著提升。例如，在一个复杂的前端页面中，有多个图表组件需要根据后端传来的数据进行实时更新，这些图表组件就可以作为观察者，而数据源头作为主题，当数据变化时，各个图表组件独立更新，互不干扰，且添加或移除某个图表组件都不会影响到其他组件以及数据源头的逻辑。
- 具备良好的扩展性：在前端应用的后续开发或者功能迭代过程中，如果有新的功能模块需要对主题的状态变化做出响应，只需要将这个新模块按照观察者的规范进行实现，然后注册到主题中即可，操作非常便捷。比如，在一个实时数据展示的前端页面中，原本只有柱状图组件关注数据的更新并进行展示，后续新增了折线图组件也需要实时更新展示数据，那么只需要将折线图组件作为观察者添加到数据这个主题对象中就行，不需要对原有的柱状图组件以及数据发布逻辑做大规模的改动。
3. 缺点
- 过多依赖引发维护难题：当观察者的数量不断增多，或者观察者之间存在较为复杂的交互逻辑时，整个系统的复杂度会急剧上升。一旦某个观察者的更新方法出现错误，或者观察者之间的通知链条出现问题，排查和定位问题的难度会变得很大，维护成本也会相应提高。例如，在一个大型的多人协作开发的前端项目中，有多个不同的模块都作为观察者监听同一个主题的状态变化，若其中一个模块的更新逻辑出现兼容性问题，可能会影响到其他模块的正常运行，而要找出问题所在，需要梳理众多模块之间的关系和逻辑，耗费大量的时间和精力。
- 存在内存泄漏风险：在使用观察者模式时，如果没有合理地对观察者进行移除操作，尤其是当某个观察者不再需要关注主题状态变化时，它依然会保留在主题的观察者列表中，这就可能导致内存中一直存在对该观察者对象以及相关引用对象的占用，随着时间的推移，容易引发内存泄漏问题，进而影响应用的性能和稳定性。比如，在一个动态加载和卸载组件的页面中，如果组件卸载时没有及时将其从对应的主题观察者列表中移除，就可能造成内存泄漏。
4. 使用案例
在前端的响应式框架（如 Vue.js 的响应式原理部分有类似思想）中，观察者模式得到了很好的应用。当数据（类似主题）发生变化时，依赖这些数据的组件（类似观察者）会自动重新渲染更新视图。这使得开发者在编写组件时，只需要关注数据的使用和展示逻辑，无需手动去监听数据的每一次变化并触发视图更新，大大提高了开发效率，同时也保证了视图与数据的一致性。另外，在实时聊天应用中，消息的推送通知机制也可以基于观察者模式来构建。新消息发布（主题状态改变）相当于有新消息产生，各个聊天窗口（观察者）接收到通知后，就会展示新消息，从而保证了每个聊天窗口都能实时显示最新的聊天内容，为用户提供了良好的聊天体验。
三、工厂模式
1. 概念及原理
工厂模式着重于将对象的创建过程进行封装，实现对象创建与使用的分离，把创建对象的具体逻辑集中放置在一个工厂函数或者工厂类里面。通过向工厂传递不同的条件或者参数，工厂就能依据这些信息来创建出不同类型的对象，就如同现实中的工厂根据不同的生产订单生产出各式各样的产品一样。
在前端开发中，当面临需要创建多个具有相似结构但又存在一定差异的对象时，工厂模式的优势就凸显出来了。例如，在构建大型前端应用时，往往会涉及大量不同类型的 UI 组件，像按钮组件、输入框组件、下拉菜单组件等，这些组件虽然都属于 UI 范畴，但它们在结构、属性、渲染方式以及所承载的功能等方面都有所不同。此时，使用工厂模式来统一管理这些组件的创建过程，既能提高代码的复用性，又便于后续的维护和扩展。
以下是一个简单的创建不同类型 UI 组件的工厂函数示例（实际应用场景中，组件的结构和创建逻辑会复杂得多，会涉及更多的属性设置、样式处理以及事件绑定等内容）：
function ComponentFactory(type) {
if (type === 'button') {
return {
render: function () {
return '<button>我是按钮</button>';
}
};
} else if (type === 'input') {
return {
render: function () {
return '<input type="text" />';
}
};
}
return null;
}
const buttonComponent = ComponentFactory('button');
const inputComponent = ComponentFactory('input');
console.log(buttonComponent.render());
console.log(inputComponent.render());
2. 优点
- 提高代码复用性：由于对象创建的逻辑被统一封装在工厂中，当在不同的地方都需要创建类似的对象时，只需要调用工厂函数并传入相应的参数即可，无需在每个使用的地方都重复编写创建对象的具体代码，这大大减少了代码的冗余，提高了代码的复用程度。例如，在一个包含多个页面的前端应用中，多个页面都需要使用到按钮组件，通过工厂模式创建按钮组件，无论在哪个页面需要按钮，都可以复用工厂中创建按钮的逻辑，保证了按钮组件创建的一致性，同时也使代码更加简洁。
- 利于维护和扩展：当业务需求发生变化，比如需要创建新类型的对象或者对现有对象的创建逻辑进行修改时，只需要在工厂内部进行相应的调整就行，对使用这些对象的其他代码部分影响较小。比如，随着设计风格的改变，需要给按钮组件添加新的样式属性或者修改其渲染方式，只需要在工厂函数中对应按钮创建的逻辑部分进行修改，而使用按钮组件的其他页面逻辑无需变动，降低了因业务变化带来的代码修改风险，提高了代码的可维护性和扩展性。
3. 缺点
- 工厂模块可能变得复杂臃肿：倘若需要创建的对象类型众多，那么工厂函数或者工厂类内部的逻辑就会变得相当复杂，会充斥着大量的判断条件分支以及不同的创建逻辑代码，这无疑会降低代码的可读性，使得后续的维护和理解变得困难。例如，在一个功能丰富的大型前端应用中，可能需要创建几十种不同类型的 UI 组件，对应的工厂函数里判断创建条件的代码会很长且繁杂，开发人员在阅读和维护这个工厂函数时，需要花费大量的时间去梳理各种创建逻辑，容易出现理解偏差和修改错误。
- 不符合开闭原则的局限性：开闭原则强调软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。而在工厂模式中，当需要新增一种创建对象的逻辑时，往往需要修改工厂函数或类的内部代码，而不是简单地通过扩展来实现，这在一定程度上违背了开闭原则，不利于代码的长期可维护性和扩展性优化。例如，要新增一种特殊的 UI 组件创建逻辑，可能需要在工厂函数中添加新的判断分支和创建代码，这就涉及到对现有工厂函数的修改，而不是单纯地添加新的模块或函数来实现扩展。
4. 使用案例
在前端构建大型应用时，创建不同类型的页面组件（如表单组件、列表组件等）可以使用工厂模式。通过工厂模式，开发人员能够按照页面的布局和功能需求，便捷地创建出各种组件并进行组装，提高开发效率。还有在游戏开发中，创建不同种类的游戏角色（不同属性、外观的角色）也可以通过工厂模式来统一管理创建过程。比如根据游戏剧情发展，需要创建不同种族、不同技能的游戏角色，利用工厂模式可以根据角色类型参数来生成相应的角色对象，方便游戏世界的构建和扩展，同时也便于对角色相关的属性和逻辑进行统一管理和调整。
四、策略模式
1. 概念及原理
策略模式的核心思想是将一系列的算法进行独立封装，使得每个算法都成为一个可独立存在且相互之间可以替换使用的单元。在前端开发中，当面对不同的业务场景需要依据不同的规则来执行相应的操作逻辑时，策略模式就能发挥出重要作用，帮助我们构建更加清晰、灵活且易于维护的代码结构。
例如，在电商类前端应用中，计算商品总价的场景就是策略模式的一个典型应用场景。根据不同的用户会员等级，商品会有不同的折扣算法，不同的折扣算法就可以看作是一个个独立的策略。通过将这些不同的折扣算法分别封装起来，然后根据用户的会员等级来选择对应的策略进行总价计算，这样一来，不仅代码结构更加清晰，各个折扣算法之间互不干扰，而且在后续业务规则发生变化，比如调整会员折扣力度或者新增会员等级时，只需要修改对应的策略函数内部逻辑或者添加新的策略函数即可，不会影响到其他使用总价计算的代码部分，便于维护和扩展。
以下是一个简单的根据会员等级计算商品总价的代码示例（实际应用中会结合更多业务逻辑和数据处理，比如商品的原价获取、优惠叠加等情况）：
const strategies = {
normal: function (price) {
return price;
},
silver: function (price) {
return price * 0.9;
},
gold: function (price) {
return price * 0.8;
}
};
function calculatePrice(price, level) {
return strategies[level](price);
}
const price = 100;
const normalPrice = calculatePrice(price, 'normal');
const silverPrice = calculatePrice(price, 'silver');
const goldPrice = calculatePrice(price, 'gold');
console.log(normalPrice, silverPrice, goldPrice);
2. 优点
- 算法可灵活替换：由于每个算法都被封装成独立的策略，当业务规则发生变化，需要调整某个算法时，比如修改会员折扣规则，只需要修改对应的策略函数内部逻辑即可，而不会影响到其他使用总价计算的代码部分，保证了代码的稳定性和可维护性。不同的策略之间可以方便地进行替换，以适应不同的业务场景需求。例如，在促销活动期间，针对特定商品可以临时更换折扣策略，只需要在调用总价计算的地方切换对应的策略名称就行，操作简单且不会引发其他相关代码的连锁反应。
- 遵循开闭原则利于扩展：在不改变原有代码结构的基础上，可以轻松地添加新的策略来应对新出现的业务情况。例如，新增更高级别的会员折扣策略或者特殊活动的折扣策略时，只需要在策略对象中添加新的函数来定义相应的算法，然后在合适的地方调用即可，代码的扩展性得到了很好的保障。
3. 缺点
- 策略过多导致管理难度上升：如果在一个应用中存在大量的策略需要维护，那么要清楚地了解每个策略的具体功能、适用场景以及它们之间的差异等信息就会变得比较麻烦。例如，有几十种不同业务场景下的计算策略时，对于开发人员来说，查找和管理这些策略的成本会显著增加，容易出现混淆和错误使用的情况。
- 客户端使用存在一定复杂度：客户端代码在调用策略时需要清楚地知道具体有哪些策略可供选择以及对应的名称等信息，这在一定程度上增加了使用的复杂度。而且如果策略的调用逻辑分散在多个地方，当策略发生变化时，需要确保所有调用的地方都进行相应的调整，否则容易出现逻辑错误。
4. 使用案例
在前端的表单验证中可以使用策略模式，比如对于不同类型的输入框（文本框、邮箱框、密码框等）有不同的验证规则，每个验证规则就是一个策略，根据输入框类型选择相应策略进行验证。另外，在图片加载时，根据不同的网络环境（如 WiFi、4G、3G 等）采用不同的图片加载策略（加载高清图、中图、低清图等）也是策略模式的应用场景。
综上所述，不同的前端设计模式各有其适用场景、优缺点，在实际的前端开发项目中，需要根据具体的业务需求、项目规模等因素合理选择和运用这些设计模式，以提高代码的可维护性、扩展性和复用性等。
