依赖注入（Dependency Injection）模式在 JS 应用中的实现与测试性提升

好的，各位观众老爷们，欢迎来到今天的“代码脱口秀”！我是你们的老朋友，人称“Bug终结者”，外号“代码诗人”的程序猿老王。今天咱们要聊聊一个让代码更优雅、更易测的“神奇魔法”——依赖注入（Dependency Injection），简称DI。

开场白：你是不是也曾被“意大利面条式代码”缠绕？🍝

话说，咱们写代码的时候，是不是经常遇到这种情况：一个模块A，里面要用到模块B的功能，然后A就像个“熊孩子”一样，直接跑到B家里去“拿”东西。时间一长，A和B就纠缠不清，你中有我，我中有你，活生生一盘“意大利面条式代码”！ 🍜 别说维护了，光是看着就头大！

更可怕的是，你想给A做个测试，结果发现A对B依赖太深，你得先把B的环境搭起来，才能测A。这简直就是“测试五分钟，环境两小时”的噩梦啊！ 😱

所以，今天咱们就来学习一下如何用“依赖注入”这把“手术刀”，把这些“意大利面条”理顺，让代码模块之间各司其职，互不干扰，最终实现代码的“高内聚，低耦合”。

第一幕：什么是依赖注入？（别被名字吓跑！）

别看“依赖注入”这个名字听起来高大上，其实它背后的思想非常简单：“别自己找，别人给！”

想象一下，你是个厨师，要做一道“宫保鸡丁”。

• 传统做法： 你自己跑去菜市场买鸡肉、花生、辣椒，然后自己切、自己炸、自己调料…… 累个半死！
• 依赖注入做法： 你告诉服务员：“我要一份处理好的鸡肉丁、炸好的花生米、切好的辣椒段、调好的宫保汁。” 服务员把这些东西直接送到你面前，你只需要把它们炒在一起就行了！ 😎

在这个例子中：

• 你是模块A（要做“宫保鸡丁”这个功能）
• 鸡肉、花生、辣椒、宫保汁是模块B（A需要依赖的“服务”）
• 服务员是“注入器”（负责把B“注入”到A中）

所以，依赖注入就是把模块A所依赖的模块B，不是由A自己去创建或查找，而是由“注入器”从外部“注入”到A中。

第二幕：依赖注入的三种姿势（总有一款适合你！）

依赖注入的实现方式有很多种，但在JS中最常见的有三种：

1. 构造函数注入（Constructor Injection）： 通过构造函数来注入依赖。
2. Setter方法注入（Setter Injection）： 通过setter方法来注入依赖。
3. 接口注入（Interface Injection）： 通过接口来注入依赖。 (JS中接口概念比较弱，通常用duck typing实现)

咱们一个一个来看：

1. 构造函数注入：

这是最常见，也是最推荐的一种方式。

// 假设我们需要一个UserService来处理用户相关的逻辑
class UserService {
  constructor(apiClient) { // 通过构造函数注入ApiClient
    this.apiClient = apiClient;
  }

  getUser(id) {
    return this.apiClient.get(`/users/${id}`);
  }
}

//ApiClient 负责和后端API交互
class ApiClient {
  constructor(baseUrl) {
    this.baseUrl = baseUrl;
  }
  get(url) {
    // 模拟API请求
    return Promise.resolve({id: 1, name: '老王'});
  }
}

// 创建ApiClient实例
const apiClient = new ApiClient('https://api.example.com');

// 创建UserService实例，并注入ApiClient
const userService = new UserService(apiClient);

userService.getUser(1).then(user => {
  console.log(user); // 输出: {id: 1, name: '老王'}
});

优点：

• 依赖关系清晰：一看构造函数就知道UserService依赖ApiClient。
• 不可变性：依赖在创建时就确定了，之后无法修改，更安全。
• 强制性：必须提供依赖，否则无法创建UserService实例。

缺点：

• 如果依赖太多，构造函数会变得很长，不利于阅读。

2. Setter方法注入：

通过setter方法来设置依赖。

class ArticleService {
  constructor() {
    this.repository = null; // 初始值为null
  }

  setRepository(repository) {
    this.repository = repository;
  }

  getArticle(id) {
    return this.repository.get(id);
  }
}

class ArticleRepository {
  get(id) {
    return Promise.resolve({id: 1, title: '依赖注入真好玩'});
  }
}

const articleService = new ArticleService();
const articleRepository = new ArticleRepository();

// 通过setter方法注入ArticleRepository
articleService.setRepository(articleRepository);

articleService.getArticle(1).then(article => {
  console.log(article); // 输出: {id: 1, title: '依赖注入真好玩'}
});

优点：

• 灵活性高：可以随时修改依赖。
• 可选性：依赖不是必须的，可以先创建对象，再设置依赖。

缺点：

• 依赖关系不清晰：需要查看代码才能知道依赖关系。
• 可变性：依赖可以被修改，可能导致意外的bug。
• 容易忘记注入依赖，导致运行时错误。

3. 接口注入（Duck Typing）：

JS本身没有接口的概念，但我们可以通过“鸭子类型（Duck Typing）”来模拟接口。 简单来说，如果一个对象“走起来像鸭子，叫起来像鸭子”，那我们就认为它是鸭子。 🦆

// 定义一个“接口” (其实就是约定)
class LoggerInterface {
  log(message) {
    throw new Error('Method "log" must be implemented.');
  }
}

class ConsoleLogger {
  log(message) {
    console.log(`[LOG]: ${message}`);
  }
}

class FileLogger {
  log(message) {
    // 写入文件...
    console.log(`[FILE]: ${message}`); // 模拟写入文件
  }
}

class OrderService {
  constructor(logger) {
    // 假设logger必须有log方法
    if (typeof logger.log !== 'function') {
      throw new Error('Logger must implement the log method.');
    }
    this.logger = logger;
  }

  createOrder(orderData) {
    this.logger.log(`Creating order: ${JSON.stringify(orderData)}`);
    // 创建订单的逻辑...
    return Promise.resolve({orderId: 123});
  }
}

const consoleLogger = new ConsoleLogger();
const fileLogger = new FileLogger();

const orderService1 = new OrderService(consoleLogger);
const orderService2 = new OrderService(fileLogger);

orderService1.createOrder({items: ['商品A', '商品B']}).then(order => {
  console.log(order);
});

orderService2.createOrder({items: ['商品C', '商品D']}).then(order => {
  console.log(order);
});

优点：

• 解耦性强：OrderService只依赖LoggerInterface，不关心具体的Logger实现。
• 灵活性高：可以方便地切换不同的Logger实现。

缺点：

• 类型检查弱：依赖于开发者自觉遵守“接口”约定。
• 代码可读性稍差：需要查看代码才能知道具体的依赖关系。

第三幕：依赖注入的好处（测试性提升是王道！）

说了这么多，依赖注入到底有什么好处呢？ 最大的好处就是：提升代码的可测试性！

咱们回到“UserService”的例子：

class UserService {
  constructor(apiClient) {
    this.apiClient = apiClient;
  }

  getUser(id) {
    return this.apiClient.get(`/users/${id}`);
  }
}

如果没有依赖注入，UserService直接依赖真实的ApiClient，那么在测试UserService的时候，就必须依赖真实的API环境。 这意味着：

• 你需要搭建一个可用的API服务。
• 你的测试会受到网络环境的影响，不稳定。
• 你无法模拟API返回的各种情况（比如错误）。

但是，有了依赖注入，我们就可以在测试的时候，注入一个“MockApiClient”！ 🎭

// MockApiClient 模拟ApiClient
class MockApiClient {
  get(url) {
    // 模拟API返回数据
    if (url === '/users/1') {
      return Promise.resolve({id: 1, name: '测试用户'});
    } else {
      return Promise.reject(new Error('User not found'));
    }
  }
}

// 测试 UserService
describe('UserService', () => {
  it('should return user data when user exists', async () => {
    const mockApiClient = new MockApiClient();
    const userService = new UserService(mockApiClient); // 注入 MockApiClient

    const user = await userService.getUser(1);
    expect(user).toEqual({id: 1, name: '测试用户'});
  });

  it('should throw an error when user does not exist', async () => {
    const mockApiClient = new MockApiClient();
    const userService = new UserService(mockApiClient);

    await expectAsync(userService.getUser(2)).toBeRejectedWithError('User not found');
  });
});

通过注入MockApiClient，我们就可以：

• 完全隔离UserService和API环境，保证测试的独立性。
• 模拟API返回的各种情况，覆盖更多的测试用例。
• 加快测试速度，提高测试效率。

除了提升测试性，依赖注入还有以下好处：

• 降低耦合度： 模块之间只依赖接口，不依赖具体实现，更容易修改和扩展。
• 提高代码复用性： 同一个依赖可以被多个模块复用。
• 提高代码可读性： 依赖关系清晰明了，更容易理解和维护。

第四幕：依赖注入容器（DI Container）

如果你的项目比较大，依赖关系比较复杂，手动管理依赖关系会变得很繁琐。 这时候，就可以使用“依赖注入容器（DI Container）”来自动化管理依赖关系。

DI Container就像一个“智能服务员”，你只需要告诉它每个模块需要哪些依赖，它就会自动帮你创建实例，并注入到相应的模块中。

JS有很多DI Container的库，比如：tsyringe, inversify-ts 等。

这里以tsyringe为例简单展示：

import 'reflect-metadata'; // 必须导入
import { container, injectable, inject } from 'tsyringe';

// 定义一个接口
interface ILogger {
  log(message: string): void;
}

// 实现接口
@injectable()
class ConsoleLogger implements ILogger {
  log(message: string): void {
    console.log(`[LOG]: ${message}`);
  }
}

// 使用依赖注入
@injectable()
class ProductService {
  constructor(@inject(ConsoleLogger) private logger: ILogger) {}

  getProduct(id: number) {
    this.logger.log(`Fetching product with id: ${id}`);
    return Promise.resolve({id: id, name: 'Awesome Product'});
  }
}

// 注册依赖关系
container.register<ILogger>(ConsoleLogger, { useClass: ConsoleLogger });

// 获取ProductService实例
const productService = container.resolve(ProductService);

productService.getProduct(123).then(product => {
  console.log(product);
});

简单解释一下：

• @injectable() 装饰器： 标记一个类可以被DI Container管理。
• @inject(ConsoleLogger) 装饰器： 告诉DI Container，ProductService的logger属性需要注入ConsoleLogger的实例。
• container.register<ILogger>(ConsoleLogger, { useClass: ConsoleLogger });： 注册Logger接口和ConsoleLogger的实现。
• container.resolve(ProductService)： 从DI Container中获取ProductService的实例，DI Container会自动创建并注入依赖。

使用DI Container可以大大简化依赖管理，提高代码的可维护性。

第五幕：总结与建议

今天咱们聊了依赖注入的概念、实现方式和好处。 总结一下：

• 依赖注入是一种设计模式， 旨在降低模块之间的耦合度，提高代码的可测试性、可维护性和可复用性。
• 常见的依赖注入方式有三种： 构造函数注入、Setter方法注入和接口注入。
• 依赖注入最大的好处是提升测试性， 可以通过注入Mock对象来隔离测试环境。
• 可以使用DI Container来自动化管理依赖关系， 简化开发。

最后，给各位观众老爷们一些建议：

• 从小处着手： 不要一开始就试图在整个项目中使用依赖注入，可以先从一些关键模块开始。
• 选择合适的注入方式： 构造函数注入是最推荐的方式，但也要根据实际情况灵活选择。
• 善用DI Container： 如果项目比较大，依赖关系比较复杂，可以考虑使用DI Container。
• 多实践，多思考： 只有在实践中才能真正理解依赖注入的精髓。

好了，今天的“代码脱口秀”就到这里。 希望大家都能掌握依赖注入这个“神奇魔法”，写出更优雅、更易测的代码！ 感谢大家的收看，咱们下期再见！ 👋