1. 为什么我们需要SOLID原则在TypeScript严格模式下开发时我经常遇到这样的困境明明功能实现了但代码却变得越来越难以维护。每次修改一个功能就会引发一连串的bug。这正是SOLID原则要解决的问题。SOLID原则由Robert C. Martin提出包含五个面向对象设计的基本原则。它们不是教条而是经过验证的最佳实践。特别是在TypeScript严格模式下遵循这些原则能让你的代码更健壮、更易扩展。注意严格模式下的TypeScript会对类型检查更加严格这恰好与SOLID原则追求代码质量的目标不谋而合。2. SOLID原则详解与TypeScript实践2.1 单一职责原则(SRP)SRP要求一个类只应该有一个引起它变化的原因。在TypeScript中我们可以这样实现// 违反SRP的例子 class User { constructor(public name: string, public email: string) {} saveToDatabase() { // 数据库操作 } sendEmail() { // 发送邮件逻辑 } } // 遵循SRP的重构 class User { constructor(public name: string, public email: string) {} } class UserRepository { save(user: User) { // 数据库操作 } } class EmailService { send(user: User) { // 发送邮件逻辑 } }在实际项目中我经常看到开发者把太多职责塞进一个类。这样做的后果是测试变得困难修改一个功能可能影响其他功能代码复用性降低2.2 开闭原则(OCP)OCP指出软件实体应该对扩展开放对修改关闭。TypeScript的接口和抽象类是实现这一原则的利器interface PaymentProcessor { process(amount: number): void; } class CreditCardProcessor implements PaymentProcessor { process(amount: number) { console.log(Processing credit card payment: ${amount}); } } class PayPalProcessor implements PaymentProcessor { process(amount: number) { console.log(Processing PayPal payment: ${amount}); } } class PaymentService { constructor(private processor: PaymentProcessor) {} executePayment(amount: number) { this.processor.process(amount); } }这种设计的好处是添加新的支付方式不需要修改现有代码更容易进行单元测试降低系统各部分之间的耦合度2.3 里氏替换原则(LSP)LSP强调子类必须能够替换它们的父类而不影响程序的正确性。在TypeScript严格模式下这尤为重要class Rectangle { constructor(public width: number, public height: number) {} setWidth(width: number) { this.width width; } setHeight(height: number) { this.height height; } get area() { return this.width * this.height; } } class Square extends Rectangle { constructor(size: number) { super(size, size); } setWidth(width: number) { super.setWidth(width); super.setHeight(width); } setHeight(height: number) { super.setWidth(height); super.setHeight(height); } } function testRectangle(rect: Rectangle) { rect.setWidth(10); rect.setHeight(5); console.assert(rect.area 50, Area should be 50); } // 这会失败因为Square违反了LSP testRectangle(new Square(5));这个例子展示了看似合理的继承关系实际上可能违反LSP。在严格模式下TypeScript的类型系统可以帮助我们发现这类问题。2.4 接口隔离原则(ISP)ISP建议客户端不应该被迫依赖它们不使用的接口。在TypeScript中我们可以这样应用// 违反ISP interface Worker { work(): void; eat(): void; sleep(): void; } // 遵循ISP interface Workable { work(): void; } interface Eatable { eat(): void; } interface Sleepable { sleep(): void; } class HumanWorker implements Workable, Eatable, Sleepable { work() { /*...*/ } eat() { /*...*/ } sleep() { /*...*/ } } class RobotWorker implements Workable { work() { /*...*/ } }在实际项目中臃肿的接口会导致不必要的依赖实现类被迫实现不需要的方法接口变更影响范围过大2.5 依赖倒置原则(DIP)DIP指出高层模块不应该依赖低层模块两者都应该依赖抽象。TypeScript的依赖注入可以这样实现interface Logger { log(message: string): void; } class ConsoleLogger implements Logger { log(message: string) { console.log(message); } } class FileLogger implements Logger { log(message: string) { // 写入文件的逻辑 } } class App { constructor(private logger: Logger) {} run() { this.logger.log(App started); // 应用逻辑 } } // 使用时 const app new App(new ConsoleLogger()); app.run();这种设计的好处包括更容易替换具体实现便于单元测试可以注入mock对象降低模块间的耦合度3. TypeScript严格模式下的特殊考量TypeScript的严格模式strict: true会启用所有严格类型检查选项。在与SOLID原则结合使用时有几个要点需要注意严格的空检查确保你的依赖注入不会意外传入null或undefinedclass App { constructor(private logger: Logger) { if (!logger) { throw new Error(Logger is required); } } }严格的属性初始化在依赖倒置时确保所有必需的依赖都在构造函数中初始化class App { private logger: Logger; // 错误未初始化 constructor(logger: Logger) { this.logger logger; } }严格的函数类型检查确保接口中的方法签名在实现时完全匹配interface Processor { process(data: string): number; } class StringProcessor implements Processor { process(data: string) { // 参数类型必须匹配 return data.length; } }4. 实际项目中的SOLID应用经验4.1 何时应该应用SOLID原则根据我的经验SOLID原则最适合以下场景长期维护的项目多人协作的代码库需要频繁扩展的功能模块对稳定性要求高的核心业务逻辑对于简单的脚本或一次性代码过度设计反而会增加不必要的复杂度。4.2 SOLID原则的常见误用过度分解把每个小功能都拆分成单独的类导致代码难以跟踪建议保持适度一个类应该代表一个有意义的业务概念过早抽象在没有明确需求变化点的情况下创建抽象建议等到第一次需要变化时再引入抽象忽视可读性为了遵循原则而使代码变得难以理解建议SOLID应该使代码更清晰而不是更复杂4.3 性能考量SOLID原则有时会引入额外的抽象层可能影响性能。但在大多数应用中抽象带来的性能开销可以忽略不计可维护性的提升往往比微小的性能优化更重要真正的性能瓶颈通常在其他地方5. 测试与SOLID原则遵循SOLID原则的代码通常更容易测试。以下是一些测试技巧单一职责的类更容易进行单元测试因为测试点更集中// 测试UserRepository test(should save user to database, () { const repo new UserRepository(); const user new User(John, johnexample.com); expect(() repo.save(user)).not.toThrow(); });依赖注入可以轻松注入mock对象进行测试// 测试App with mock logger test(should log on startup, () { const mockLogger { log: jest.fn() }; const app new App(mockLogger); app.run(); expect(mockLogger.log).toHaveBeenCalledWith(App started); });接口隔离可以只mock必要的接口方法6. 重构现有代码的步骤当你要将现有代码重构为遵循SOLID原则时可以按照以下步骤识别问题点查找经常修改的类查找难以测试的组件查找包含多个职责的类小步重构每次只解决一个问题确保有完善的测试覆盖频繁提交便于回滚常用重构手法提取类Extract Class提取接口Extract Interface引入参数对象Introduce Parameter Object用组合替代继承Replace Inheritance with Delegation验证重构运行所有测试检查性能影响确保功能不变7. TypeScript特性与SOLID的协同效应TypeScript的某些特性特别适合实现SOLID原则接口和类型别名完美支持ISP和DIP// 使用类型别名实现ISP type Workable { work: () void; }; type Eatable { eat: () void; };抽象类支持OCP和LSPabstract class Shape { abstract area(): number; } class Circle extends Shape { constructor(private radius: number) { super(); } area() { return Math.PI * this.radius ** 2; } }装饰器可以在不修改原有类的情况下扩展功能function log(target: any, key: string, descriptor: PropertyDescriptor) { const original descriptor.value; descriptor.value function(...args: any[]) { console.log(Calling ${key} with, args); return original.apply(this, args); }; return descriptor; } class Calculator { log add(a: number, b: number) { return a b; } }泛型支持创建更通用的抽象interface RepositoryT { save(entity: T): void; findById(id: string): T | undefined; } class UserRepository implements RepositoryUser { // 具体实现 }8. 常见问题解答QSOLID原则是否适用于函数式编程虽然SOLID原则起源于面向对象编程但其中的许多思想也适用于函数式编程。例如单一职责可以对应纯函数的单一功能开闭原则可以对应高阶函数接口隔离可以对应小型、专注的函数签名Q如何平衡SOLID原则和开发速度在项目初期可以适当放宽某些原则以快速验证想法。但随着代码规模增长应该逐步重构以遵循SOLID原则。关键是找到平衡点。QSOLID原则是否会导致类数量爆炸确实可能增加类的数量但每个类的复杂度会降低。现代IDE的导航功能使得管理大量小类并不困难。更重要的是代码的可维护性。Q在TypeScript中接口和抽象类如何选择偏好使用接口因为它们更轻量级。只有在需要提供部分实现或需要构造函数约束时才使用抽象类。Q如何说服团队成员遵循SOLID原则最有效的方法是展示实际好处演示如何轻松修改遵循SOLID的代码展示测试的便利性对比维护SOLID代码和非SOLID代码的时间成本 
长河君 · 2026/10/27 11:07:12 · 阅读 1.2k TypeScript严格模式下实践SOLID原则指南
1. 为什么我们需要SOLID原则在TypeScript严格模式下开发时我经常遇到这样的困境明明功能实现了但代码却变得越来越难以维护。每次修改一个功能就会引发一连串的bug。这正是SOLID原则要解决的问题。SOLID原则由Robert C. Martin提出包含五个面向对象设计的基本原则。它们不是教条而是经过验证的最佳实践。特别是在TypeScript严格模式下遵循这些原则能让你的代码更健壮、更易扩展。注意严格模式下的TypeScript会对类型检查更加严格这恰好与SOLID原则追求代码质量的目标不谋而合。2. SOLID原则详解与TypeScript实践2.1 单一职责原则(SRP)SRP要求一个类只应该有一个引起它变化的原因。在TypeScript中我们可以这样实现// 违反SRP的例子 class User { constructor(public name: string, public email: string) {} saveToDatabase() { // 数据库操作 } sendEmail() { // 发送邮件逻辑 } } // 遵循SRP的重构 class User { constructor(public name: string, public email: string) {} } class UserRepository { save(user: User) { // 数据库操作 } } class EmailService { send(user: User) { // 发送邮件逻辑 } }在实际项目中我经常看到开发者把太多职责塞进一个类。这样做的后果是测试变得困难修改一个功能可能影响其他功能代码复用性降低2.2 开闭原则(OCP)OCP指出软件实体应该对扩展开放对修改关闭。TypeScript的接口和抽象类是实现这一原则的利器interface PaymentProcessor { process(amount: number): void; } class CreditCardProcessor implements PaymentProcessor { process(amount: number) { console.log(Processing credit card payment: ${amount}); } } class PayPalProcessor implements PaymentProcessor { process(amount: number) { console.log(Processing PayPal payment: ${amount}); } } class PaymentService { constructor(private processor: PaymentProcessor) {} executePayment(amount: number) { this.processor.process(amount); } }这种设计的好处是添加新的支付方式不需要修改现有代码更容易进行单元测试降低系统各部分之间的耦合度2.3 里氏替换原则(LSP)LSP强调子类必须能够替换它们的父类而不影响程序的正确性。在TypeScript严格模式下这尤为重要class Rectangle { constructor(public width: number, public height: number) {} setWidth(width: number) { this.width width; } setHeight(height: number) { this.height height; } get area() { return this.width * this.height; } } class Square extends Rectangle { constructor(size: number) { super(size, size); } setWidth(width: number) { super.setWidth(width); super.setHeight(width); } setHeight(height: number) { super.setWidth(height); super.setHeight(height); } } function testRectangle(rect: Rectangle) { rect.setWidth(10); rect.setHeight(5); console.assert(rect.area 50, Area should be 50); } // 这会失败因为Square违反了LSP testRectangle(new Square(5));这个例子展示了看似合理的继承关系实际上可能违反LSP。在严格模式下TypeScript的类型系统可以帮助我们发现这类问题。2.4 接口隔离原则(ISP)ISP建议客户端不应该被迫依赖它们不使用的接口。在TypeScript中我们可以这样应用// 违反ISP interface Worker { work(): void; eat(): void; sleep(): void; } // 遵循ISP interface Workable { work(): void; } interface Eatable { eat(): void; } interface Sleepable { sleep(): void; } class HumanWorker implements Workable, Eatable, Sleepable { work() { /*...*/ } eat() { /*...*/ } sleep() { /*...*/ } } class RobotWorker implements Workable { work() { /*...*/ } }在实际项目中臃肿的接口会导致不必要的依赖实现类被迫实现不需要的方法接口变更影响范围过大2.5 依赖倒置原则(DIP)DIP指出高层模块不应该依赖低层模块两者都应该依赖抽象。TypeScript的依赖注入可以这样实现interface Logger { log(message: string): void; } class ConsoleLogger implements Logger { log(message: string) { console.log(message); } } class FileLogger implements Logger { log(message: string) { // 写入文件的逻辑 } } class App { constructor(private logger: Logger) {} run() { this.logger.log(App started); // 应用逻辑 } } // 使用时 const app new App(new ConsoleLogger()); app.run();这种设计的好处包括更容易替换具体实现便于单元测试可以注入mock对象降低模块间的耦合度3. TypeScript严格模式下的特殊考量TypeScript的严格模式strict: true会启用所有严格类型检查选项。在与SOLID原则结合使用时有几个要点需要注意严格的空检查确保你的依赖注入不会意外传入null或undefinedclass App { constructor(private logger: Logger) { if (!logger) { throw new Error(Logger is required); } } }严格的属性初始化在依赖倒置时确保所有必需的依赖都在构造函数中初始化class App { private logger: Logger; // 错误未初始化 constructor(logger: Logger) { this.logger logger; } }严格的函数类型检查确保接口中的方法签名在实现时完全匹配interface Processor { process(data: string): number; } class StringProcessor implements Processor { process(data: string) { // 参数类型必须匹配 return data.length; } }4. 实际项目中的SOLID应用经验4.1 何时应该应用SOLID原则根据我的经验SOLID原则最适合以下场景长期维护的项目多人协作的代码库需要频繁扩展的功能模块对稳定性要求高的核心业务逻辑对于简单的脚本或一次性代码过度设计反而会增加不必要的复杂度。4.2 SOLID原则的常见误用过度分解把每个小功能都拆分成单独的类导致代码难以跟踪建议保持适度一个类应该代表一个有意义的业务概念过早抽象在没有明确需求变化点的情况下创建抽象建议等到第一次需要变化时再引入抽象忽视可读性为了遵循原则而使代码变得难以理解建议SOLID应该使代码更清晰而不是更复杂4.3 性能考量SOLID原则有时会引入额外的抽象层可能影响性能。但在大多数应用中抽象带来的性能开销可以忽略不计可维护性的提升往往比微小的性能优化更重要真正的性能瓶颈通常在其他地方5. 测试与SOLID原则遵循SOLID原则的代码通常更容易测试。以下是一些测试技巧单一职责的类更容易进行单元测试因为测试点更集中// 测试UserRepository test(should save user to database, () { const repo new UserRepository(); const user new User(John, johnexample.com); expect(() repo.save(user)).not.toThrow(); });依赖注入可以轻松注入mock对象进行测试// 测试App with mock logger test(should log on startup, () { const mockLogger { log: jest.fn() }; const app new App(mockLogger); app.run(); expect(mockLogger.log).toHaveBeenCalledWith(App started); });接口隔离可以只mock必要的接口方法6. 重构现有代码的步骤当你要将现有代码重构为遵循SOLID原则时可以按照以下步骤识别问题点查找经常修改的类查找难以测试的组件查找包含多个职责的类小步重构每次只解决一个问题确保有完善的测试覆盖频繁提交便于回滚常用重构手法提取类Extract Class提取接口Extract Interface引入参数对象Introduce Parameter Object用组合替代继承Replace Inheritance with Delegation验证重构运行所有测试检查性能影响确保功能不变7. TypeScript特性与SOLID的协同效应TypeScript的某些特性特别适合实现SOLID原则接口和类型别名完美支持ISP和DIP// 使用类型别名实现ISP type Workable { work: () void; }; type Eatable { eat: () void; };抽象类支持OCP和LSPabstract class Shape { abstract area(): number; } class Circle extends Shape { constructor(private radius: number) { super(); } area() { return Math.PI * this.radius ** 2; } }装饰器可以在不修改原有类的情况下扩展功能function log(target: any, key: string, descriptor: PropertyDescriptor) { const original descriptor.value; descriptor.value function(...args: any[]) { console.log(Calling ${key} with, args); return original.apply(this, args); }; return descriptor; } class Calculator { log add(a: number, b: number) { return a b; } }泛型支持创建更通用的抽象interface RepositoryT { save(entity: T): void; findById(id: string): T | undefined; } class UserRepository implements RepositoryUser { // 具体实现 }8. 常见问题解答QSOLID原则是否适用于函数式编程虽然SOLID原则起源于面向对象编程但其中的许多思想也适用于函数式编程。例如单一职责可以对应纯函数的单一功能开闭原则可以对应高阶函数接口隔离可以对应小型、专注的函数签名Q如何平衡SOLID原则和开发速度在项目初期可以适当放宽某些原则以快速验证想法。但随着代码规模增长应该逐步重构以遵循SOLID原则。关键是找到平衡点。QSOLID原则是否会导致类数量爆炸确实可能增加类的数量但每个类的复杂度会降低。现代IDE的导航功能使得管理大量小类并不困难。更重要的是代码的可维护性。Q在TypeScript中接口和抽象类如何选择偏好使用接口因为它们更轻量级。只有在需要提供部分实现或需要构造函数约束时才使用抽象类。Q如何说服团队成员遵循SOLID原则最有效的方法是展示实际好处演示如何轻松修改遵循SOLID的代码展示测试的便利性对比维护SOLID代码和非SOLID代码的时间成本