SOLID 五大原则中文实战：从代码示例理解面向对象设计

单一职责原则的核心是：一个类应该只有一个改变的理由，也就是说一个类应该只负责一项功能。

违反示例（TypeScript）：

// 反例：用户类同时处理用户逻辑、数据库和邮件
class User {
  name: string;
  email: string;

constructor(name: string, email: string) { this.name = name; this.email = email; }

// 职责 1：用户信息管理 getInfo() { return ${this.name} (${this.email}); }

// 职责 2：数据库保存 saveToDatabase() { console.log('Saving to DB...'); // SQL 逻辑混在这里 }

// 职责 3：发送邮件 sendWelcomeEmail() { console.log('Sending email to ' + this.email); // SMTP 配置混在这里 } } ```

问题：如果数据库连接方式改变、邮件服务换了、用户字段增删，都要修改这个类。三个不同的改变理由。

修正示例：

// 职责 1：用户信息
class User {
  name: string;
  email: string;

constructor(name: string, email: string) { this.name = name; this.email = email; }

getInfo() { return ${this.name} (${this.email}); } }

// 职责 2：持久化 class UserRepository { save(user: User) { console.log('Saving to DB...'); // 只关心如何存 } }

// 职责 3：通知 class EmailService { send(email: string, subject: string, body: string) { console.log(Sending to ${email}: ${subject}); // 只关心如何发邮件 } } ```

Java 对比：

// 修正的 Java 版本
public class User {
    private String name;
    private String email;

public User(String name, String email) { this.name = name; this.email = email; }

public String getInfo() { return name + " (" + email + ")"; } }

public class UserRepository { public void save(User user) { // 仅处理数据库逻辑 } }

public class EmailNotifier { public void notifyNewUser(User user) { // 仅处理邮件发送 } } ```

常见误区： - 把 SRP 理解成「一个方法做一件事」——那是函数内聚，级别更细。SRP 是类级别的原则。 - 过度拆分——把一个类拆成 10 个单方法类，反而增加了复杂度。合理的粒度是关键。

开闭原则：对扩展开放，对修改关闭。意思是当需要新功能时，应该通过扩展（新增类、方法）而不是改动现有代码。

违反示例：

// 反例：每加一种支付方式，都要改 PaymentProcessor 类
class PaymentProcessor {
  processPayment(amount: number, type: string) {
    if (type === 'credit_card') {
      console.log(`Processing credit card payment: ${amount}`);
      // 信用卡逻辑
    } else if (type === 'paypal') {
      console.log(`Processing PayPal payment: ${amount}`);
      // PayPal 逻辑
    } else if (type === 'wechat') {
      console.log(`Processing WeChat payment: ${amount}`);
      // 微信支付逻辑
    }
    // 每次加支付方式都要改这个方法
  }
}

缺点：新增支付方式就要修改现有代码，引入 bug 风险。

修正示例（使用接口 + 多态）：

// 定义支付接口
interface PaymentMethod {
  pay(amount: number): void;
}

// 各种支付方式实现接口 class CreditCardPayment implements PaymentMethod { pay(amount: number) { console.log(Processing credit card payment: ${amount}); } }

class PayPalPayment implements PaymentMethod { pay(amount: number) { console.log(Processing PayPal payment: ${amount}); } }

class WeChatPayment implements PaymentMethod { pay(amount: number) { console.log(Processing WeChat payment: ${amount}); } }

// 处理器只依赖接口，对扩展开放，对修改关闭 class PaymentProcessor { processPayment(amount: number, method: PaymentMethod) { method.pay(amount); // 多态调用 } }

// 使用 const processor = new PaymentProcessor(); processor.processPayment(100, new CreditCardPayment()); processor.processPayment(100, new WeChatPayment()); // 加新支付方式：只需新增类，不修改 PaymentProcessor ```

Java 对比：

public interface PaymentMethod {
    void pay(double amount);
}

public class AliPayPayment implements PaymentMethod { @Override public void pay(double amount) { System.out.println("AliPay: " + amount); } }

public class PaymentProcessor { public void process(double amount, PaymentMethod method) { method.pay(amount); } } ```

关键：使用接口、抽象类、多态来支持新功能，而不是修改现有类。

里氏替换原则：子类应该能够替换父类，而不破坏程序的正确性。也就是说，子类的行为应该与父类一致，符合约定（契约）。

违反示例：

// 反例：鸭子类和橡皮鸭继承关系不当
class Duck {
  swim() {
    console.log('Duck swimming');
  }

fly() { console.log('Duck flying'); } }

// 橡皮鸭是 Duck 的子类？逻辑上不对 class RubberDuck extends Duck { swim() { console.log('Rubber duck floating'); }

fly() { // 橡皮鸭不会飞！违反了 Duck 的约定 throw new Error('RubberDuck cannot fly!'); } }

// 使用时出问题 function makeDuckFly(duck: Duck) { duck.fly(); // 传入 RubberDuck 时崩溃 }

makeDuckFly(new RubberDuck()); // 错误！ ```

修正示例（重新设计继承结构）：

// 基类：所有水禽共同行为
abstract class Waterfowl {
  swim() {
    console.log('Swimming');
  }
}

// 只能游的鸭子 class RubberDuck extends Waterfowl { // 继承 swim，不需要 fly }

// 能飞的鸭子 abstract class FlyingBird extends Waterfowl { fly() { console.log('Flying'); } }

class MallardDuck extends FlyingBird { // 既能游，也能飞 }

// 现在多态是安全的 function makeDuckFly(bird: FlyingBird) { bird.fly(); // 只接受能飞的，类型系统保证安全 }

makeDuckFly(new MallardDuck()); // OK makeDuckFly(new RubberDuck()); // 编译错误，类型不匹配 ```

Java 对比：

public abstract class Shape {
    public abstract double getArea();
}

// 正方形：边长 = 宽度 = 高度 public class Square extends Shape { private double side;

public Square(double side) { this.side = side; }

@Override public double getArea() { return side * side; } }

// 矩形：宽度 != 高度 public class Rectangle extends Shape { private double width; private double height;

public Rectangle(double width, double height) { this.width = width; this.height = height; }

@Override public double getArea() { return width * height; } }

// 里氏替换：传入 Rectangle，行为符合预期 Shape shape = new Rectangle(3, 4); // area = 12 ```

常见误区： - 认为「子类继承父类」就自动满足 LSP。实际上要检查子类是否破坏了父类的契约。 - 正方形是矩形的数学真理，但在代码中不一定要这样继承。设计应该服从业务逻辑，不是现实。

接口隔离原则：不应该强迫客户端依赖他们不使用的接口。接口应该细粒度，而不是大而全。

违反示例：

// 反例：大而全的 Worker 接口
interface Worker {
  work(): void;
  eat(): void;
  sleep(): void;
}

class Developer implements Worker { work() { console.log('Coding'); }

eat() { console.log('Eating lunch'); }

sleep() { console.log('Sleeping 8 hours'); } }

// 机器人是 Worker 吗？它能工作，但不需要吃饭和睡眠 class Robot implements Worker { work() { console.log('Processing data'); }

eat() { // 机器人不吃饭，被迫实现 throw new Error('Robots do not eat'); }

sleep() { // 机器人不睡眠，被迫实现 throw new Error('Robots do not sleep'); } } ```

问题：Robot 被迫实现不需要的方法。

修正示例（拆分接口）：

// 细粒度接口
interface Workable {
  work(): void;
}

interface Eatable { eat(): void; }

interface Sleepable { sleep(): void; }

// 人实现需要的接口 class Developer implements Workable, Eatable, Sleepable { work() { console.log('Coding'); } eat() { console.log('Eating'); } sleep() { console.log('Sleeping'); } }

// 机器人只实现需要的接口 class Robot implements Workable { work() { console.log('Processing'); } }

// 客户端也可以选择只依赖需要的接口 function makeWorker(worker: Workable) { worker.work(); // 只调用这一个方法 }

makeWorker(new Developer()); makeWorker(new Robot()); // 两者都可以，无冲突 ```

Java 对比：

// 拆分后的接口
public interface Readable {
    void read();
}

public interface Writable { void write(); }

public class SimpleReader implements Readable { @Override public void read() { System.out.println("Reading file"); } }

public class ReadWriter implements Readable, Writable { @Override public void read() { / ... / }

@Override public void write() { / ... / } }

// 客户端只依赖需要的接口 public class FileProcessor { public void process(Readable reader) { reader.read(); } } ```

常见误区： - 接口越小越好——过度细化会导致接口爆炸，反而增加复杂度。 - ISP 不是说接口必须只有一个方法。合理的粒度是相关功能打包为一个接口。

依赖倒置原则有两层含义：

1. 高层模块不应依赖低层模块，两者都应依赖于抽象（接口）。
2. 抽象不应依赖于细节，细节应依赖于抽象。

违反示例：

// 反例：高层 OrderService 直接依赖低层具体类 MySQLDatabase
class MySQLDatabase {
  saveOrder(order: any) {
    console.log('Saving to MySQL');
  }
}

class OrderService { private db: MySQLDatabase; // 直接依赖具体类

constructor() { this.db = new MySQLDatabase(); // 紧耦合 }

placeOrder(order: any) { // ... 业务逻辑 this.db.saveOrder(order); } }

// 问题：要切换到 MongoDB，必须改 OrderService，违反开闭原则 ```

修正示例（依赖注入 + 接口）：

// 定义数据库接口
interface IDatabase {
  saveOrder(order: any): void;
}

// 具体实现 class MySQLDatabase implements IDatabase { saveOrder(order: any) { console.log('Saving to MySQL'); } }

class MongoDatabase implements IDatabase { saveOrder(order: any) { console.log('Saving to MongoDB'); } }

// 高层模块依赖于接口，不依赖具体类 class OrderService { constructor(private db: IDatabase) {} // 注入依赖

placeOrder(order: any) { // ... 业务逻辑 this.db.saveOrder(order); } }

// 使用：可以灵活切换数据库实现 const mySQLDb = new MySQLDatabase(); const service1 = new OrderService(mySQLDb);

const mongoDb = new MongoDatabase(); const service2 = new OrderService(mongoDb); // 无需改 OrderService ```

Java 对比（Spring 框架示例）：

public interface IOrderRepository {
    void save(Order order);
}

public class MySQLOrderRepository implements IOrderRepository { @Override public void save(Order order) { // MySQL 逻辑 } }

public class OrderService { private IOrderRepository repository;

// 依赖注入（Spring 框架会自动注入） @Autowired public OrderService(IOrderRepository repository) { this.repository = repository; }

public void placeOrder(Order order) { repository.save(order); } }

// Spring 配置： // @Bean // public IOrderRepository orderRepository() { // return new MySQLOrderRepository(); // } ```

关键：通过注入接口而非具体类，实现松耦合。高层业务逻辑与低层实现细节分离。

1. 创建订单（支持多种支付方式）
2. 持久化（支持多种数据库）
3. 发送通知（邮件、短信、推送）
4. 计算优惠（不同会员等级不同折扣）

完整设计示例：

// 1. 接口隔离：定义细粒度接口
interface PaymentMethod {
  pay(amount: number): boolean;
}

interface OrderRepository { save(order: Order): void; findById(id: string): Order | null; }

interface OrderNotifier { notify(orderId: string, message: string): void; }

interface DiscountStrategy { calculate(amount: number): number; // 返回折扣后金额 }

// 2. 依赖倒置：定义高层服务 class OrderService { constructor( private repository: OrderRepository, private paymentMethod: PaymentMethod, private notifier: OrderNotifier, private discountStrategy: DiscountStrategy ) {}

createOrder(items: Item[], memberId: string): Order { // S: 单一职责 - 只负责创建订单逻辑 let total = items.reduce((sum, item) => sum + item.price, 0);

// 计算折扣 total = this.discountStrategy.calculate(total);

const order = new Order(items, total, memberId);

// O: 开闭原则 - 支付和通知通过接口扩展，不修改这个方法 const paid = this.paymentMethod.pay(total); if (!paid) throw new Error('Payment failed');

// 单一职责：保存和通知委托给其他对象 this.repository.save(order); this.notifier.notify(order.id, 'Order created');

return order; } }

// 3. 开闭原则 + 依赖倒置：具体实现 class CreditCardPayment implements PaymentMethod { pay(amount: number): boolean { console.log('Charging credit card: ' + amount); return true; } }

class MySQLOrderRepository implements OrderRepository { save(order: Order) { console.log('Saving to MySQL: ' + order.id); } findById(id: string) { return null; } }

class EmailNotifier implements OrderNotifier { notify(orderId: string, message: string) { console.log('Email to customer: ' + message); } }

// L: 里氏替换原则 class PremiumMemberDiscount implements DiscountStrategy { calculate(amount: number): number { return amount * 0.9; // 9 折 } }

class RegularMemberDiscount implements DiscountStrategy { calculate(amount: number): number { return amount * 0.95; // 9.5 折 } }

// 4. 使用：高层逻辑与实现分离 const service = new OrderService( new MySQLOrderRepository(), new CreditCardPayment(), new EmailNotifier(), new PremiumMemberDiscount() );

const order = service.createOrder(items, 'member123');

// 切换为 SMS 通知？新增 SMSNotifier 类，注入即可，不修改 OrderService // 切换为阿里支付？新增 AliPayPayment 类，注入即可 ```

这个设计体现了： - S：OrderService 只负责编排业务流程 - O：新增支付/通知方式无需改 OrderService - L：各实现类可互相替换 - I：接口细粒度，不强迫实现不需要的方法 - D：高层依赖接口，通过构造函数注入低层实现

1. 过度设计：为了遵循 SOLID，给简单的两文件项目做了 20 个接口。适度才是王道，复杂度要与项目规模匹配。

1. 弄反了 LSP 和 ISP：LSP 是关于行为兼容性，ISP 是关于接口粒度。犯一个常见的错：实现了太大的接口，导致子类 throw 异常——这是 ISP 违反，不是 LSP。

1. 把 DIP 当作「所有依赖都注入」：DIP 不是说要把所有东西都外部注入。只有那些容易变化的、需要解耦的才注入。基础库、工具类不需要注入。

1. 接口继承链太深：

1. 遗漏异常处理：抽象后容易让团队成员对各实现类的异常行为模糊。在接口文档或 JSDoc 中明确说明可能抛出的异常。

1. 配置而非代码：有些框架提供声明式配置（如 Spring 的注解）来应用 SOLID。但本质还是代码设计，配置只是辅助。理解原则本身比框架更重要。

1. 单测覆盖不足：SOLID 能帮助写更易测的代码（依赖注入、接口隔离），但最后还要用单测验证。设计好了，测试也得跟上。

1. 递进式学习：不要一次性学五个原则。先掌握 S 和 D（最常用），再学 O、L、I。

1. 实战优于理论：在自己的项目中尝试，遇到问题再看原则。被动背诵效果差。

1. 代码审查：review 团队的代码时，用 SOLID 作为检查清单。「这个类有几个改变理由？」「这个接口是否强迫实现不需要的方法？」

1. 参考书籍：

1. 常见设计模式与 SOLID 的关系：

1. 框架学习：Spring、Django、.NET 等框架内置了大量 SOLID 应用。研究框架源码是最好的学习材料。