Angular中带实现方法的抽象类与Service的差异及适用场景

我们有两种实现逻辑一致的代码——一种是让组件继承含实现方法的抽象类，另一种是把相同逻辑做成Service注入到组件中。这两种方式存在差异吗？如果有，差异是什么？如果没有，该怎么选？

代码对比 #

方式一：组件继承抽象类 #

abstract class Base {
    name: string = "";

    getName(){
       return this.name;
    }
} 

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css']
})
export class HomeComponent extends Base implements OnInit {

}

vs 方式二：注入Service #

@Injectable()
export class BaseService {
    name: string = "";

    getName(){
       return this.name;
    }
}

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css'],
  providers: [BaseService]
})
export class HomeComponent implements OnInit {

    constructor(private baseService: BaseService) {}

}

核心差异 #

1. 实例与作用域 #

• 抽象类继承：每个HomeComponent实例都会自带抽象类的属性和方法，name是组件实例的一部分，生命周期完全和组件绑定，组件销毁时这部分状态也会被回收。
• Service注入：如果在组件的providers中声明，每个组件实例会对应一个独立的BaseService实例；如果在模块级别提供，整个模块内是单例。name属于Service实例，生命周期由Angular注入容器管理。

2. 复用范围 #

• 抽象类：只能通过类继承复用，仅限类（比如组件、指令）使用，复用受限于继承层级，无法给Service、守卫等其他Angular单元复用。
• Service：可以注入到任何Angular支持依赖注入的地方——组件、Service、守卫、管道、指令等，不需要继承，复用更灵活。

3. 测试灵活性 #

• 抽象类：组件继承后，要替换抽象类的逻辑需要重写方法或mock整个继承链，操作繁琐，耦合度高。
• Service：依赖注入模式下，测试时可以轻松替换成mock的Service实例，无需修改组件代码，测试成本更低。

4. 职责划分 #

• 抽象类：组件继承后会承担抽象类的逻辑，容易让组件职责混杂——组件本该专注视图交互，抽象类的业务逻辑会和视图逻辑耦合，违反单一职责原则。
• Service：把逻辑剥离到Service中，组件只负责调用Service获取数据或执行逻辑，职责清晰，符合Angular“组件负责视图，Service负责业务”的设计模式。

5. 状态共享能力 #

• 抽象类：每个组件实例的状态（比如name）完全独立，无法在多个组件间共享状态。
• Service：如果是模块级单例Service，多个组件注入的是同一个实例，天然支持跨组件状态共享；若需要组件独立状态，也可以通过组件级提供Service实现。

选择依据 #

• 选抽象类：当逻辑是组件专属、和组件生命周期强绑定、不需要跨单元复用的时候，比如多个组件有相同的视图控制逻辑（如通用表单状态管理、视图加载状态处理）。
• 选Service：当逻辑是业务逻辑、需要跨组件/Service复用、需要状态共享、追求低耦合易测试的时候，比如数据请求、全局状态管理、通用工具方法等。

内容的提问来源于stack exchange，提问作者Alan-A