前端框架中的设计模式 ｜ 豆包MarsCode AI 刷题

用户054785131983
71 阅读19分钟

单例模式

  • 详细介绍：
    单例模式的核心在于确保一个类仅有一个实例，并提供一个全局访问点来获取该实例。在前端开发环境中，它常用于管理那些在整个应用生命周期内只应存在一个的资源或状态，比如全局配置、唯一的模态框实例等。其实现原理通常借助闭包来隐藏实例的创建过程，控制实例的唯一性。

以 JavaScript 为例，当应用首次调用获取单例实例的方法时，会进行实例的创建操作；后续再次调用获取实例的方法时，直接返回已创建好的那个实例，而不会重复创建，以此保证整个应用中只有一个这样的对象存在。

  • 优点：

    • 节省内存：由于只存在一个实例，避免了因创建多个相同功能或状态的对象而带来的额外内存开销。例如在一个大型网页应用中，如果有多个地方都需要获取应用的基础配置信息（如主题颜色、字体大小等），若没有单例模式，每个地方都创建一个配置对象，不仅浪费内存，还可能导致配置不一致的情况出现。而通过单例模式，所有地方都共享同一个配置实例，能有效节省内存并保证配置的统一性。
    • 便于全局访问和管理：提供了统一的访问入口，使得不同模块、不同组件在需要使用该单例对象所管理的资源或执行相关操作时，可以方便地获取到它。例如在一个多页面的网站中，不管用户处于哪个页面，都可以通过同一个全局的音频播放器单例实例来控制音乐的播放、暂停等操作，实现了跨页面的统一管理。

  • 缺点：

    • 违反单一职责原则：单例类往往不仅要负责创建唯一的实例，还可能承担诸多业务逻辑相关的功能，导致其职责不够单一。比如一个管理用户登录状态的单例对象，可能既要负责记录登录状态，又要处理与登录相关的各种业务逻辑，如权限验证、用户信息获取等，使得代码的维护难度随着功能的增加而增大，因为对其中某一职责的修改可能影响到其他相关部分。
    • 不利于单元测试：在进行单元测试时，由于单例实例在全局是唯一的，很难去模拟不同的实例状态来进行独立的测试。例如在测试一个依赖全局主题配置单例的组件时，难以隔离该单例的影响，去单独验证组件在不同主题配置下的表现，可能需要复杂的测试设置来处理单例依赖问题，增加了测试的复杂性。

  • 使用案例：

    • 网站主题切换管理：
      在一个电商网站中，为了给用户提供不同的视觉体验，往往会支持主题切换功能，如在浅色模式和深色模式之间切换。整个网站应用内只需要一个对象来管理当前的主题配置状态，这个对象通过单例模式实现再合适不过。
      以下是示例代码（以简单的 JavaScript 对象模拟）：
const ThemeManager = (function () {
    let instance;
    function createInstance() {
        return {
            currentTheme: 'light', // 默认浅色模式
            setTheme: function (newTheme) {
                this.currentTheme = newTheme;
                // 这里可以添加代码来实际更新页面的样式，比如切换 CSS 类名等操作
                document.body.className = newTheme;
                console.log(`主题已切换为 ${newTheme} 模式`);
            },
            getTheme: function () {
                return this.currentTheme;
            }
        };
    }
    return {
        getInstance: function () {
            if (!instance) {
                instance = createInstance();
            }
            return instance;
        }
    };
})();

const themeManager1 = ThemeManager.getInstance();
const themeManager2 = ThemeManager.getInstance();
themeManager1.setTheme('dark');
console.log(themeManager2.getTheme()); // 输出 'dark'，说明两个引用指向的是同一个实例，能保持主题状态的一致性

在这个案例中，无论用户在网站的哪个页面进行主题切换操作，都是通过 ThemeManager 的单例实例来改变和获取当前主题状态，保证了整个网站主题的一致性，并且只占用一份内存来存储主题相关信息。

  • 全局音频播放器控制：
    在一个在线音乐播放平台网页上，不管用户处于歌曲列表页查看歌曲，还是在播放详情页正在收听歌曲，操作播放、暂停、切换歌曲等功能都是针对同一个音频播放器实例进行的。通过单例模式确保整个应用只有这一个音频播放器对象来管理播放相关的状态和操作，示例代码如下：
const AudioPlayer = (function () {
    let instance;
    function createInstance() {
        const audioElement = new Audio(); // 创建 HTML5 音频元素
        return {
            play: function (src) {
                audioElement.src = src;
                audioElement.play();
            },
            pause: function () {
                audioElement.pause();
            },
            seek: function (time) {
                audioElement.currentTime = time;
            }
        };
    }
    return {
        getInstance: function () {
            if (!instance) {
                instance = createInstance();
            }
            return instance;
        }
    };
})();

const player1 = AudioPlayer.getInstance();
const player2 = AudioPlayer.getInstance();
player1.play('https://example.com/music/song1.mp3');
player2.pause(); // 同样能操作同一个音频播放器实例来暂停播放

借助单例模式，避免了创建多个音频播放器导致的音频播放混乱以及内存浪费等问题，让用户在不同页面进行音频操作时，始终是对同一个播放器实例进行交互，保证了播放状态的连贯性和一致性。

观察者模式（发布 - 订阅模式）

  • 详细介绍：
    观察者模式定义了一种一对多的依赖关系，在这个模式中有主题（发布者）和观察者（订阅者）两个核心角色。主题对象负责维护一组观察者对象，并在自身状态发生变化时，主动通知所有已注册的观察者对象，而观察者对象则事先向主题对象注册自己感兴趣的事件，当接收到主题对象的通知后，执行相应的更新操作。

在前端开发中，这种模式的应用非常广泛，它其实和浏览器中的事件机制类似。例如，给一个 HTML 元素添加点击事件监听器，元素就是发布者，当用户点击这个元素（状态变化，即触发点击事件）时，就会通知所有绑定的事件处理函数（观察者）来执行相应的逻辑。

实现观察者模式时，通常会创建一个事件中心（主题对象），它内部维护着不同事件类型对应的观察者函数列表，具备注册观察者（on 方法，用于订阅事件）和触发通知（emit 方法，用于发布事件）等功能。

  • 优点：

    • 解耦性强：发布者和订阅者之间是一种松散耦合的关系，发布者无需知晓具体有哪些订阅者在关注它，只需要专注于自身状态的改变并发布相应事件即可；而订阅者也不用关心事件是如何产生的，只需要在接收到感兴趣的事件通知后，执行自身的处理逻辑。这种解耦使得各个模块可以独立开发、测试和维护，例如在一个复杂的电商应用中，商品库存管理模块作为发布者，商品详情页、购物车页等作为订阅者，库存管理模块的修改不会直接影响到依赖它的其他页面模块，只要事件的发布和订阅机制不变，各个模块就能正常协同工作。
    • 支持广播通信：能够方便地实现消息的广播，一个事件可以同时通知多个订阅者，使得在一些需要多模块同时响应某个操作或状态变化的场景中非常好用。比如在一个社交网络应用中，用户发布了一条新动态，可能需要通知关注该用户的好友列表模块、消息推送模块、动态展示模块等多个地方同时进行更新，通过观察者模式就能轻松实现这种一对多的广播式通知。

  • 缺点：

    • 过度使用可能导致代码难以理解：如果在一个项目中大量使用观察者模式，创建了众多的事件发布和订阅关系，整个流程的跟踪会变得复杂起来。开发人员可能很难清晰地知道在某个特定情况下，到底哪些地方会触发哪些事件，以及各个订阅者对这些事件又做了何种处理，这会增加代码的维护成本和阅读难度，尤其是对于新加入项目的开发人员来说，理解这样的代码逻辑可能会花费较多时间。
    • 可能存在内存泄漏问题：由于订阅者需要向发布者注册自己（添加事件监听），如果在订阅者对象不再需要接收通知时（比如一个组件被销毁了），没有正确地取消订阅（移除对应的事件监听），那么发布者内部依然会保留着对这些订阅者函数的引用，导致内存中一直占用着这部分空间，随着时间推移和应用的运行，可能会造成内存泄漏，影响应用的性能。

  • 使用案例：

    • 用户登录状态通知：
      在一个包含多个页面模块的社交网络应用中，当用户登录成功这一状态发生变化时，很多相关模块都需要做出相应的反应。比如导航栏要显示用户的头像和昵称，侧边栏要展示用户的好友列表，消息中心要更新未读消息数量等。可以利用观察者模式来实现这种通知机制，代码示例如下：
// 定义事件中心（发布者）
const eventHub = {
    events: {},
    on: function (eventName, callback) {
        if (!this.events[eventName]) {
            this.events[eventName] = [];
        }
        this.events[eventName].push(callback);
    },
    emit: function (eventName, data) {
        const callbacks = this.events[eventName];
        if (callbacks && callbacks.length > 0) {
            callbacks.forEach(callback => callback(data));
        }
    }
};

// 导航栏模块（订阅者之一）
const navbar = {
    updateUserInfo: function (userData) {
        console.log(`导航栏更新用户信息：头像 - ${userData.avatar}，昵称 - ${userData.nickname}`);
        // 实际代码中这里会操作 DOM 来更新显示内容
    }
};
eventHub.on('userLoggedIn', navbar.updateUserInfo);

// 侧边栏模块（订阅者之二）
const sidebar = {
    updateFriendList: function (userData) {
        console.log(`侧边栏更新好友列表，当前用户好友数量：${userData.friendCount}`);
        // 真实场景下会渲染好友列表到侧边栏 DOM 元素上
    }
};
eventHub.on('userLoggedIn', sidebar.updateFriendList);

// 模拟用户登录成功后发布事件及传递用户数据
const userData = {
    avatar: 'https://example.com/avatar.jpg',
    nickname: 'JohnDoe',
    friendCount: 100
};
eventHub.emit('userLoggedIn', userData);

通过这种方式，用户登录成功后，登录相关的逻辑只需要在一处（发布者）发布 userLoggedIn 事件并传递用户数据，而各个需要响应登录状态变化的模块（订阅者）都能接收到通知并执行相应的更新操作，实现了不同模块之间的松散耦合通信。

  • 商品库存变化通知：
    在一个电商购物平台中，商品的库存数量会随着进货、用户下单等操作而发生变化，当库存变化时，多个相关模块需要知晓这个情况并做出相应处理。库存管理系统作为发布者，商品详情页、购物车页等作为订阅者，示例代码如下：
// 库存管理中心（发布者）
const inventoryManager = {
    events: {},
    on: function (eventName, callback) {
        if (!this.events[eventName]) {
            this.events[eventName] = [];
        }
        this.events[eventName].push(callback);
    },
    emit: function (eventName, data) {
        const callbacks = this.events[eventName];
        if (callbacks && callbacks.length > 0) {
            callbacks.forEach(callback => callback(data));
        }
    },
    updateInventory: function (productId, newQuantity) {
        // 这里可以是实际更新数据库中库存数量等操作
        console.log(`商品 ${productId} 的库存已更新为 ${newQuantity}`);
        this.emit('inventoryChanged', { productId, newQuantity });
    }
};

// 商品详情页模块（订阅者之一）
const productDetailPage = {
    updateStockDisplay: function (data) {
        console.log(`商品详情页更新库存显示，商品 ${data.productId} 现在库存为 ${data.newQuantity}`);
        // 在页面上找到对应的库存显示元素并更新其内容
    }
};
inventoryManager.on('inventoryChanged', productDetailPage.updateStockDisplay);

// 购物车模块（订阅者之二）
const shoppingCart = {
    checkStockAvailability: function (data) {
        console.log(`购物车检查商品 ${data.productId} 的库存情况，当前库存为 ${data.newQuantity}`);
        // 根据库存数量判断商品是否还能继续购买等逻辑处理
    }
};
inventoryManager.on('inventoryChanged', shoppingCart.checkStockAvailability);

// 模拟库存更新操作并发布事件
inventoryManager.updateInventory('P001', 10);

这样，不管是因为进货增加库存还是用户下单减少库存，库存管理系统在更新库存后发布 inventoryChanged 事件，商品详情页和购物车页等订阅者都能及时获取到库存变化信息并进行相应的页面展示和逻辑处理，保证了整个电商平台各相关模块关于库存信息的一致性和实时性。

工厂模式

  • 详细介绍：
    工厂模式是一种创建对象的设计模式，它的主要目的是将对象的创建和使用分离，把对象创建的复杂逻辑封装在一个工厂函数或者工厂类中。通过这种方式，当需要创建对象时，只需要调用工厂提供的相应方法，而无需关心对象具体是如何创建出来的，比如初始化属性、分配内存等细节。

在前端开发中，当面临创建多种类型且具有相似创建过程的对象时，工厂模式能发挥很大作用。例如创建不同类型的 UI 组件，每个组件都有一些共同的属性（如类型、样式类名等），但又有各自特定的属性和创建逻辑，使用工厂模式可以统一管理这些组件的创建过程，提高代码的复用性和可维护性。

工厂模式通常有简单工厂、工厂方法、抽象工厂等不同的实现形式，简单工厂模式是最基础的一种，它直接在一个工厂函数中根据传入的参数来决定创建哪种类型的对象；工厂方法模式则是把创建方法放到具体的工厂子类中，由子类来决定创建具体的对象；抽象工厂模式更为复杂，用于创建一系列相关的产品对象族，但在前端中相对使用较少，简单工厂模式在实际应用中较为常见。

  • 优点：

    • 代码复用性高：对于创建同一类或者相似类型的对象，把创建逻辑放在工厂中，避免了在多个地方重复编写创建对象的代码。比如在一个网页表单中，需要创建多个不同的表单元素（文本框、下拉框、单选框等），每个表单元素都有一些共同的初始化操作（如添加到表单容器、设置基本样式等），通过工厂模式将这些通用的创建步骤封装起来，只在工厂函数中编写一次，在需要创建具体表单元素时调用工厂相应的创建方法即可，大大提高了代码的复用程度。
    • 便于维护和扩展：当需要修改对象的创建逻辑，比如添加新的属性或者改变创建的条件时，只需要在工厂函数或类内部进行修改，不会影响到使用这些对象的其他代码部分。例如，要给所有创建的表单元素添加一个统一的 data-validation 属性用于前端验证，只需要在工厂函数里修改创建逻辑，添加这个属性的赋值操作，而使用这些表单元素的页面逻辑代码无需做任何改动。而且后续如果要添加创建新类型对象的方法，也可以方便地在工厂中进行扩展，比如增加创建日期选择器这种新的表单元素类型。

  • 缺点：

    • 可能导致工厂类或函数过于复杂：如果要创建的对象类型繁多，且各类对象的创建逻辑差异较大，那么工厂内部的代码会变得臃肿复杂，不利于阅读和维护。例如，在一个功能非常全面的网页应用中，工厂既要创建各种表单元素，又要创建不同类型的图表组件，还要创建多种样式的弹窗组件等，不同类型对象的创建涉及到完全不同的技术和逻辑，会使得工厂函数或类的代码量大幅增加，逻辑变得混乱，开发人员在理解和修改工厂代码时会面临较大困难。
    • 不符合开闭原则（在一定程度上） ：开闭原则要求对扩展开放，对修改关闭，即软件实体（类、模块、函数等）应该可以扩展，但是不可修改。而在简单工厂模式中，当添加新的对象创建逻辑时，往往需要修改工厂类或函数的代码，虽然可以通过一些设计技巧（如使用反射机制等，不过在前端 JavaScript 中相对复杂）来缓解这个问题，但在常规的简单实现方式下较难完全遵循开闭原则。

  • 使用案例：

    • 动态创建不同类型的表单元素：
      在一个企业内部管理系统的网页中，存在各种用于不同业务场景的表单，像员工信息录入、请假申请、费用报销等表单都需要不同类型的表单元素（如文本框、下拉框、单选框、复选框等）来收集用户输入的信息。可以通过工厂模式来统一创建这些表单元素，示例代码如下：
// 定义表单元素基类
function FormElement(type, label) {
    this.type = type;
    this.label = label;
    this.element = null; // 用来存储最终生成的 DOM 元素实例
}

// 定义表单元素工厂函数
function FormElementFactory() {
    return {
        createTextInput: function (labelText) {
            const element = new FormElement('text', labelText);
            element.element = document.createElement('input');
            element.element.type = 'text';
            element.element.placeholder = labelText;
            return element;
        },
        createSelect: function (labelText, options) {
            const element = new FormElement('select', labelText);
            element.element = document.createElement('select');
            options.forEach(option => {
                const optionElement = document.createElement('option');
                optionElement.value = option.value;
                optionElement.textContent = option.text;
                element.element.appendChild(optionElement);
            });
            return element;
        },
        createRadio: function (labelText, value) {
            const element = new FormElement('radio', labelText);
            element.element = document.createElement('input');
            element.element.type = 'radio';
            element.element.value = value;
            return element;
        },
        createCheckbox: function (labelText, value) {
            const element = new FormElement('checkbox', labelText);
            element.element = document.createElement('input');
            element.element.type = 'checkbox';
            element.element.value = value;
            return element;
        }
    };
}

const factory = new FormElementFactory();
const nameInput = factory.createTextInput('姓名');
const genderSelect = factory.createSelect('性别', [
    { value: 'male', text: '男' },
    { value: 'female', text: '女' }
]);
const isMarriedRadio = factory.createRadio('是否已婚', 'yes');
const hasBenefitsCheckbox = factory.createCheckbox('是否有福利', 'yes');

// 可以将这些表单元素添加到对应的表单 DOM 结构中
const form = document.createElement('form');
form.appendChild(nameInput.element);
form.appendChild(genderSelect.element);
form.appendChild(isMarriedRadio.element);
form.appendChild(hasBenefitsCheckbox.element);
document.body.appendChild(form);

在这个案例中，通过 FormElementFactory 这个工厂函数，将不同类型表单元素的创建逻辑进行了统一封装。对于每个具体的创建方法（如 createTextInput、createSelect 等），它们都遵循一定的通用步骤（如先创建对应类型的 FormElement 实例，再生成相应的 DOM 元素并设置其基本属性），同时又针对各自类型的特点进行了特定的操作（如 select 元素添加 option 子元素等）。

这样一来，如果后续需要添加新的表单元素类型或者修改现有元素的创建逻辑（比如添加样式类名、验证属性等），只需要在 FormElementFactory 内部进行相应调整即可，而使用这些表单元素构建表单的页面逻辑代码不需要做修改，方便了代码的维护和扩展，并且提高了创建表单元素代码的复用性。

  • 生成不同风格的图表组件用于数据分析页面：
    在一个数据分析平台的网页上，为了更直观地展示各种业务数据，需要展示不同类型（如柱状图、折线图、饼图等）以及不同风格（如简约风格、科技风格等）的图表。通过工厂模式可以方便地创建这些图表，示例代码如下（以使用 ECharts 库为例，简化示意）：
// 定义图表组件基类
function ChartComponent(type, data) {
    this.type = type;
    this.data = data;
    this.chartInstance = null; // 存储图表实例
}

// 定义图表工厂函数
function ChartFactory() {
    return {
        createBarChart: function (data, theme) {
            const chart = new ChartComponent('bar', data);
            chart.chartInstance = echarts.init(document.createElement('div'), theme);
            // 配置柱状图的相关数据和样式等
            const option = {
                // 具体 ECharts 配置项省略
            };
            chart.chartInstance.setOption(option);
            return chart;
        },
        createLineChart: function (data, theme) {
            const chart = new ChartComponent('line', data);
            chart.chartInstance = echarts.init(document.createElement('div'), theme);
            // 配置折线图的相关数据和样式等
            const option = {
                // 具体 ECharts 配置项省略
            };
            chart.chartInstance.setOption(option);
            return chart;
        },
        createPieChart: function (data, theme) {
            const chart = new ChartComponent('pie', data);
            chart.chartInstance = echarts.init(document.createElement('div'), theme);
            // 配置饼图的相关数据和样式等
            const option = {
                // 具体 ECharts 配置项省略
            };
            chart.chartInstance.setOption(option);
            return chart;
        },
        createCustomChart: function (type, data, theme) {
            const chart = new ChartComponent(type, data);
            if (type === 'bar') {
                // 针对柱状图的特殊定制逻辑，比如添加特定背景颜色等
                chart.chartInstance = echarts.init(document.createElement('div'), theme);
                const option = {
                    // 特殊的柱状图配置项省略
                };
                chart.chartInstance.setOption(option);
            } else if (type === 'line') {
                // 针对折线图的特殊定制逻辑，比如添加线条动画效果等
                chart.chartInstance = echarts.init(document.createElement('div'), theme);
                const option = {
                    // 特殊的折线图配置项省略
                };
                chart.chartInstance.setOption(option);
            } else if (type === 'pie') {
                // 针对饼图的特殊定制逻辑，比如调整扇形颜色等
                chart.chartInstance = echarts.init(document.createElement('div'), theme);
                const option = {
                    // 特殊的饼图配置项省略
                };
                chart.chartInstance.setOption(option);
            }
            return chart;
        }
    };
}

const factory = new ChartFactory();
const salesData = [
    { name: '产品 A', value: 100 },
    { name: '产品 B', value: 200 },
    // 更多数据省略
];
const barChart = factory.createBarChart(salesData, 'light');
const lineChart = factory.createLineChart(salesData, 'dark');
const pieChart = factory.createPieChart(salesData, 'tech');
const customBarChart = factory.createCustomChart('bar', salesData, 'custom');

// 将图表实例添加到页面相应的 DOM 容器中展示
const chartContainer = document.createElement('div');
chartContainer.appendChild(barChart.chartInstance.getDom());
chartContainer.appendChild(lineChart.chartInstance.getDom());
chartContainer.appendChild(pieChart.chartInstance.getDom());
chartContainer.appendChild(customBarChart.chartInstance.getDom());
document.body.appendChild(chartContainer);

在这个数据分析平台的案例中，ChartFactory 作为图表工厂函数，将创建不同类型图表的复杂过程进行了封装。无论是创建常规的柱状图、折线图、饼图，还是带有特殊定制逻辑的图表（通过 createCustomChart 方法体现），都可以通过统一的工厂接口来实现。

开发人员只需要关注传入的图表类型、数据以及想要的风格等参数，无需深入了解 ECharts 库中每个图表具体的初始化、配置等底层细节。而且当需要对图表的创建逻辑进行修改（比如更新 ECharts 版本后调整配置项写法）或者添加新的图表类型（如新增雷达图等）时，只需要在 ChartFactory 内部进行相应的代码调整，不会影响到使用这些图表展示数据的页面业务逻辑代码，体现了工厂模式在创建复杂对象时便于维护和扩展的优势，同时复用了图表创建过程中的一些通用步骤（如初始化图表实例、设置基本的 DOM 容器等），提高了代码的复用性。

模块模式

  • 详细介绍：
    模块模式是一种在 JavaScript 中用于创建私有变量和方法，同时对外暴露公共接口的设计模式，它常借助闭包来实现信息隐藏和代码组织的功能。在一个模块内部，可以定义一些变量和函数，这些变量和函数默认是私有的，外部无法直接访问，只有通过模块返回的公共接口才能操作或获取相关内容。

其原理在于利用 JavaScript 中函数作用域和闭包的特性，当一个立即执行函数表达式（IIFE - Immediately Invoked Function Expression）执行时，它内部形成了一个独立的作用域，在这个作用域内定义的变量和函数不会污染全局环境，并且可以通过返回的对象来选择性地将部分功能暴露给外部使用，从而实现了类似面向对象编程中类的封装效果，只不过是基于函数作用域来实现的一种模块封装方式。

这种模式在前端开发中对于组织代码结构、保护内部数据以及实现功能模块的独立性等方面有着重要作用，尤其是在没有使用更高级的模块管理系统（如 ES6 模块、CommonJS 等）的情况下，或者对于一些简单的、独立的功能模块，模块模式能够很好地满足代码封装和复用的需求。

  • 优点：

    • 实现了数据隐藏和封装：通过将内部的变量和函数设置为私有，保护了模块内部的核心算法、敏感数据或者状态等不被外部随意访问和修改，避免了全局变量污染，使得代码更加安全和稳定。例如在一个处理用户登录验证的模块中，可能会有存储用户登录凭证的私有变量，以及验证登录信息是否正确的私有函数，这些内部细节对于外部代码是不可见的，外部只能通过模块提供的公共接口（如 login 函数来发起登录请求、isLoggedIn 函数来判断当前是否已登录等）来与模块进行交互，防止了外部代码意外修改登录相关的关键数据或逻辑，保障了登录功能的正确性和安全性。
    • 提高了代码的可维护性和组织性：将相关功能逻辑放在一个模块内，清晰地划分了功能边界，方便代码的阅读、理解以及后续的修改和扩展。比如一个包含用户信息获取、展示以及更新等功能的模块，把这些相关代码通过模块模式封装起来，开发人员在查看和维护代码时，能够很容易地定位到这个模块对应的功能代码，并且在需要对某个功能进行修改（如更新用户信息展示的样式）或者扩展（如添加新的用户信息字段获取逻辑）时，只需要在模块内部进行相应操作，不会影响到其他不相关的代码部分，使得整个项目的代码结构更加清晰有条理。

  • 缺点：

    • 对于依赖管理不够直观：如果模块之间存在复杂的依赖关系，不像一些专门的模块管理系统（如 ES6 模块通过 import 和 export 语句能清晰地声明和管理依赖，CommonJS 通过 require 函数来加载依赖等）那样能清晰地声明和管理依赖，需要手动去处理模块之间的相互引用等情况，容易出现依赖混乱的问题。例如，模块 A 依赖模块 B 的某个函数，在模块模式下可能需要在模块 A 内部通过全局变量或者特定的命名约定去获取模块 B 暴露的接口，当项目规模较大、模块众多时，这种依赖关系的梳理和维护会变得比较困难，容易出现找不到依赖或者依赖版本不一致等问题。
    • 不便于动态加载模块（在传统实现方式下） ：相对现代的模块加载机制（如浏览器的动态 import() 语法或者一些模块打包工具支持的按需加载功能），单纯的模块模式在需要动态加载模块（比如根据用户操作按需加载某个功能模块）方面缺乏便捷的支持。在传统的模块模式实现中，模块代码通常是在页面加载时就全部加载并执行了，难以实现根据特定条件（如用户点击某个按钮才加载相关模块）动态地去获取和执行模块代码，这在一定程度上限制了代码的灵活性和性能优化（例如无法实现懒加载来减少初始页面加载时间等）。

  • 使用案例：

    • 用户权限验证模块：
      在一个企业资源管理系统中，不同的用户有不同的权限（如管理员可以进行所有操作，普通员工只能查看部分数据等），需要对用户的各种操作进行权限验证。可以将权限验证相关的逻辑封装在一个模块中，通过模块模式来隐藏内部实现细节，对外只暴露验证接口，示例代码如下：
const AuthModule = (function () {
    // 模拟存储用户权限信息的对象，实际可能从服务器获取
    const userPermissions = {
        username: 'john',
        role: 'employee',
        permissions: ['read_data', 'submit_report']
    };
    // 私有函数，用于检查权限
    function hasPermission(permission) {
        return userPermissions.permissions.includes(permission);
    }
    // 对外暴露的公共函数（接口）
    return {
        canReadData: function () {
            return hasPermission('read_data');
        },
        canEditData: function () {
            return hasPermission('edit_data');
        },
        isAdmin: function () {
            return userPermissions.role === 'admin';
        }
    };
})();

const isAllowedToRead = AuthModule.canReadData();
const isAllowedToEdit = AuthModule.canEditData();
const isAdmin = AuthModule.isAdmin();
console.log(`是否允许读取数据：${isAllowedToRead}`);
console.log(`是否允许编辑数据：${isAllowedToEdit}`);
console.log(`是否为管理员：${isAdmin}`);

在这个案例中，AuthModule 通过模块模式封装了用户权限验证的功能。内部的 userPermissions 对象和 hasPermission 函数是私有的，外部无法直接访问和修改它们，保证了权限数据的安全性和验证逻辑的独立性。而对外暴露的 canReadData、canEditData 和 isAdmin 等公共接口，使得其他模块可以方便地调用这些接口来判断用户是否具有相应的权限，比如在页面渲染时，根据用户是否有权限编辑数据来决定是否显示编辑按钮等操作，实现了权限验证功能的模块化和复用性，同时隐藏了内部具体的权限存储和判断逻辑。

  • 地图导航功能模块：
    在一个出行类的手机网页应用中，地图导航是一个重要功能模块，它内部包含地图数据加载、定位获取、路径规划等复杂逻辑。通过模块模式将这些功能封装起来，对外提供简单易用的接口，示例代码如下（简化示意，实际会涉及调用地图 API 等操作）：
const MapNavigationModule = (function () {
    let currentLocation;
    // 私有函数，用于获取用户当前位置（模拟，实际调用浏览器定位 API）
    function getCurrentLocation() {
        return new Promise((resolve, reject) => {
            setTimeout(() => {
                currentLocation = { lat: 37.7749, lng: -122.4194 }; // 模拟旧金山的坐标
                resolve(currentLocation);
            }, 1000);
        });
    }
    // 私有函数，用于加载地图数据（模拟，实际从地图服务获取瓦片数据等）
    function loadMapData() {
        return new Promise((resolve, reject) => {
            setTimeout(() => {
                resolve('地图数据已加载完成');
            }, 2000);
        });
    }
    // 对外暴露的公共函数（接口）
    return {
        init: function () {
            return Promise.all([getCurrentLocation(), loadMapData()]).then(() => {
                console.log('地图导航模块初始化完成');
            });
        },
        searchRoute: function (destination) {
            console.log(`正在规划从 ${currentLocation} 到 ${destination} 的路线`);
            // 实际代码中会调用路径规划算法等，这里简单模拟返回
            return new Promise((resolve, reject) => {
                setTimeout(() => {
                    resolve(`规划的路线信息：${destination}`);
                }, 3000);
            });
        }
    };
})();

MapNavigationModule.init().then(() => {
    MapNavigationModule.searchRoute({ lat: 38.9072, lng: -77.0369 }); // 模拟搜索到华盛顿的路线
});

在这个地图导航模块的案例中，内部的 currentLocation 变量以及 getCurrentLocation 和 loadMapData 等函数都是私有的，它们共同构成了地图导航功能的内部实现细节，比如获取当前位置和加载地图数据的具体逻辑被隐藏起来，外部模块不需要关心这些复杂的操作过程。而对外暴露的 init 和 searchRoute 接口，让其他模块（比如用户界面模块在用户点击导航按钮时）可以方便地调用这些接口来初始化地图导航模块并进行路线搜索操作，实现了地图导航功能的模块化封装，提高了代码的可维护性和复用性，同时保护了内部实现的独立性和稳定性。

这些不同的设计模式在前端开发场景中都有着各自独特的价值，根据具体的项目需求和功能特点合理地选择和运用它们，能够帮助开发者构建出更加合理、可维护、高效的前端应用，提升整个项目的开发质量和效率。

avatar
文章
阅读
粉丝