如何结构化JavaScript类以实现多模块间的互相调用与通信

方案实现 #

核心实现逻辑 #

采用依赖注入模式即可解决跨模块通信问题，无需声明全局命名空间，也不会产生耦合：各业务类不需要主动导入其他模块，只需要在实例化时由入口文件（core.js）注入需要用到的外部能力即可。

具体代码示例 #

1. dialogs.js 弹窗类实现

export default class Dialogs {
  alert(content) {
    // 自定义弹窗逻辑
  }
  confirm(content, onConfirm) {
    // 自定义确认框逻辑
  }
}

2. catalogue.js 业务类实现
   不需要导入其他模块，只需要在构造函数中声明需要的依赖：

export default class Catalogue {
  // 构造函数接收注入的依赖
  constructor({ dialogApi, coreUtils }) {
    this.dialogApi = dialogApi
    this.coreUtils = coreUtils
  }

  // 业务逻辑示例：加载数据失败时触发弹窗
  loadCatalogueData() {
    fetch('/xxx/catalogue-api')
      .then(res => res.json())
      .catch(err => {
        // 直接调用注入的弹窗能力即可，不需要关心实现方
        this.dialogApi.alert(`数据加载失败：${err.message}`)
      })
  }
}

3. core.js 入口文件组装逻辑
   作为所有模块的调度方，统一实例化、注入依赖：

import Catalogue from './catalogue.js'
import Dialogs from './dialogs.js'

// 统一实例化公共模块
const dialogInstance = new Dialogs()
// 实例化业务类时注入需要的依赖
const catalogueInstance = new Catalogue({
  dialogApi: dialogInstance,
  coreUtils: {
    // 此处可以暴露所有需要给Catalogue调用的core.js内部函数
    getCurrentPageId: () => new URLSearchParams(location.search).get('pageId')
  }
})

// 正常调用业务类方法即可
catalogueInstance.loadCatalogueData()

常见疑问解答 #

• 不需要声明全局命名空间，依赖注入模式完全规避了全局变量污染问题，模块间耦合度极低，后续替换弹窗实现时不需要修改Catalogue类的任何代码。
• 该模式是目前JS模块化开发的标准实践，不存在不合理的问题。
• 你遇到的this绑定到window的问题，是因为没有启用ES模块严格模式：只要给引入JS的script标签添加type="module"属性，ES模块默认开启严格模式，顶层this为undefined，类内部的this默认绑定到实例本身，不会指向window。如果需要单独传递类方法，用箭头函数或者.bind(实例)处理即可。

相关学习资料推荐 #

• 现代JavaScript基础教程的ES模块、类特性相关章节
• 前端依赖注入模式实践相关资料
• ES6+官方标准文档

内容的提问来源于stack exchange，提问作者Zac