本文探讨了在 Angular 抽象基类中处理服务依赖注入时遇到的常见问题，特别是子类未传递服务导致空值的情况。我们将介绍 Angular 16+ 提供的 `inject` 函数作为直接解决方案，并深入讨论 Angular 架构的最佳实践——优先使用组合而非继承，以构建更健壮、可维护的应用。
在 Angular 项目开发中，我们有时会尝试通过创建抽象基类来复用代码逻辑和依赖项。然而，当在基类的构造函数中声明服务依赖，并且子类没有显式地通过 super() 调用传递这些服务时，子类中对应的服务实例往往会是 null，这给开发带来了困扰。
传统继承模式下的服务注入困境
考虑以下使用传统继承方式的场景：
// 基类
export abstract class MyBaseClass {
constructor(protected toastService?: ToastService) {}
showToast(message: string): void {
if (this.toastService) {
this.toastService.info(message);
} else {
console.warn('ToastService is not available.');
}
}
}
// 子类
export class MyChildService extends MyBaseClass {
constructor() {
// 如果不在这里传递 toastService，父类中的 toastService 将为 null
super();
}
doSomethingAndNotify(): void {
// 此时 this.toastService 在 MyBaseClass 中为 null
this.showToast('Operation completed!');
}
}在这种模式下，如果子类 MyChildService 的构造函数没有通过 super(toastService) 显式地将 ToastService 传递给父类，那么在 MyBaseClass 内部，toastService 属性将始终为 null。这使得基类中依赖该服务的逻辑无法正常执行，需要额外的空值检查。
Angular inject 函数：现代解决方案
从 Angular 16 开始，引入了 inject 函数，它提供了一种更简洁、更直接的方式来获取依赖项，而无需通过构造函数。这对于解决上述基类服务注入问题尤其有效。
inject 函数可以在类中的任何位置（除了构造函数参数列表）调用，包括类属性初始化器中，从而避免了 super() 调用的复杂性。
import { inject, Injectable } from '@angular/core';
// 假设 ToastService 是一个可注入的服务
@Injectable({ providedIn: 'root' })
export class ToastService {
info(message: string): void {
console.log(`Toast (Info): ${message}`);
}
}
// 使用 inject 函数的基类
export abstract class MyBaseClassWithInject {
protected toastService = inject(ToastService); // 直接注入，无需构造函数传递
showToast(message: string): void {
this.toastService.info(message); // toastService 保证不为 null
}
}
// 继承该基类的子类
@Injectable({ providedIn: 'root' })
export class MyChildServiceWithInject extends MyBaseClassWithInject {
constructor() {
super(); // 即使子类构造函数简单调用 super()，toastService 也已在父类中注入
}
doSomethingAndNotify(): void {
this.showToast('Operation completed with modern injection!');
}
}inject 函数的优势：
- 简化构造函数： 无需在构造函数中声明和传递依赖，使构造函数更简洁。
- 避免 super() 依赖： 子类不再需要关心父类需要哪些依赖，只需简单调用 super() 即可。
- 提高可读性： 依赖项的获取位置更靠近其使用位置。
- 类型安全： inject 函数返回的是服务的实例，无需进行空值检查。
Angular 架构最佳实践：拥抱组合而非继承
尽管 inject 函数有效解决了继承链中的服务注入问题，但在 Angular 生态系统中，普遍推荐的架构模式是组合（Composition）而非继承（Inheritance）。Angular 的设计哲学更侧重于模块化、依赖注入和装饰器，而传统的类继承在某些情况下可能导致以下问题：
- 装饰器不继承： Angular 的组件、服务等通常通过装饰器定义元数据。类继承并不会自动继承装饰器，这可能导致意外行为。
- 脆弱的基类问题： 基类的修改可能无意中影响所有子类，导致难以维护和测试。
- 多重继承限制： TypeScript 不支持多重继承，限制了代码复用的灵活性。
因此，更推荐的做法是创建独立的、可注入的服务来封装通用逻辑，并通过依赖注入将其组合到需要该逻辑的类中。
import { inject, Injectable } from '@angular/core';
// 封装通用逻辑的服务
@Injectable({ providedIn: 'root' })
export class CommonLogicService {
private toastService = inject(ToastService);
performCommonOperation(data: any): void {
console.log('Performing common operation with:', data);
this.toastService.info('Common operation completed!');
}
}
// 需要通用逻辑的类，通过组合使用 CommonLogicService
@Injectable({ providedIn: 'root' })
export class MyFeatureService {
private commonLogic = inject(CommonLogicService);
processFeatureData(featureData: string): void {
console.log(`Processing feature data: ${featureData}`);
this.commonLogic.performCommonOperation({ featureData });
// 其他特定于 MyFeatureService 的逻辑
}
}
// 另一个需要通用逻辑的类
@Injectable({ providedIn: 'root' })
export class AnotherFeatureService {
private commonLogic = inject(CommonLogicService);
handleUserAction(action: string): void {
console.log(`Handling user action: ${action}`);
this.commonLogic.performCommonOperation({ action });
}
}组合模式的优势：
- 高内聚、低耦合： 每个服务只负责单一职责，模块化程度更高。
- 更强的灵活性： 可以根据需要组合不同的服务，避免了继承的层级限制。
- 易于测试： 每个服务都可以独立测试，更容易进行单元测试。
- 符合 Angular 的 DI 哲学： 充分利用 Angular 强大的依赖注入系统。
注意事项与总结
- inject 函数版本要求： inject 函数是 Angular 16 及更高版本引入的特性。如果您的项目仍在使用旧版 Angular，则需要考虑升级或采用其他兼容旧版的方式（如将服务作为公共属性传递给子类构造函数，或在子类构造函数中重新注入）。
- 避免滥用继承： 尽管 inject 函数解决了继承中的注入问题，但这并不意味着应该在 Angular 中大量使用类继承。始终优先考虑组合和依赖注入。
- 何时使用抽象类： 抽象类在 Angular 中并非完全没有用武之地。例如，它们可以用于定义接口契约，或者在确实存在强烈的“is-a”关系且不涉及 Angular 特有元数据（如 @Component）的纯 TypeScript 逻辑复用场景。但在涉及 Angular 服务、组件生命周期等场景时，应格外谨慎。
综上所述，当您在 Angular 抽象基类中遇到服务注入问题时，Angular 16+ 的 inject 函数提供了一个直接且优雅的解决方案。然而，从更宏观的架构角度来看，拥抱组合而非继承是构建健壮、可维护的 Angular 应用的黄金法则。通过将通用逻辑封装在独立的服务中并利用依赖注入进行组合，可以更好地发挥 Angular 框架的优势。
