首页教程软件教程正文

JS里的SOLID原则是什么有什么作用

uncle 软件教程 2025年08月6日

0 收藏 0 点赞 555 浏览 3933 个字

摘要 :

文章目录单一职责原则（SRP）：让代码各司其职 1）反面案例： 2）正面案例：开闭原则（OCP）：让代码可扩展且稳定 1）反面案例： 2）正面案例：里氏替换原则（LS……

文
章
目
录

单一职责原则（SRP）：让代码各司其职

1）反面案例：
2）正面案例：

开闭原则（OCP）：让代码可扩展且稳定

1）反面案例：
2）正面案例：

里氏替换原则（LSP）：保证子类的可替代性

1）反面案例：
2）正面案例：

接口隔离原则（ISP）：拒绝臃肿，只取所需

1）反面案例：
2）正面案例：

依赖倒置原则（DIP）：依赖抽象，远离具体

1）反面案例：
2）正面案例：

为什么SOLID原则在JavaScript中如此重要？

在JavaScript编程中SOLID原则就像是一套神奇的指南，能帮我们写出高质量、易维护的代码。它包含五个重要原则，分别从不同角度规范代码的设计和编写方式。接下来，我就结合实际的JavaScript示例，给大家详细讲讲这五个原则，让大家轻松掌握它们的精髓。

单一职责原则（SRP）：让代码各司其职

简单来说，单一职责原则就是一个类或者函数只干一件事。打个比方，就像一个人在公司里只负责一个明确的工作任务一样。

1）反面案例：

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  saveToDatabase() {
    // 数据库逻辑
  }

  sendEmail() {
    // 邮件逻辑
  }
}

这段代码里的User类可不太“专一”，它既负责管理用户数据（constructor部分），又承担了保存数据到数据库（saveToDatabase方法）和发送邮件（sendEmail方法）的工作。这样一来，代码的职责就很混乱，后期维护和修改都容易出问题。

2）正面案例：

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class UserRepository {
  saveToDatabase(user) { /* 数据库逻辑 */ }
}

class EmailService {
  sendEmail(user) { /* 邮件逻辑 */ }
}

改进之后，User类只专注于管理用户数据，UserRepository类负责和数据库交互保存数据，EmailService类专门处理邮件发送。每个类都有自己明确的职责，代码变得清晰明了，维护起来也轻松多了。

开闭原则（OCP）：让代码可扩展且稳定

开闭原则的核心思想是，一个软件实体（比如类、模块、函数等）应该对扩展开放，对修改关闭。这意味着当我们需要添加新功能时，最好是通过扩展现有代码来实现，而不是直接去修改原来的代码。

1）反面案例：

class Logger {
  logToConsole(message) {
    console.log(message);
  }

  logToFile(message) {
    // 写入文件
  }
}

// 要添加一个新的记录器（例如 HTTP），必须修改 Logger 类。

在这个Logger类中，如果我们想要新增一种记录日志的方式，比如记录到HTTP服务器，就不得不直接修改Logger类的代码。这样做的风险很大，可能会影响到原来已经正常运行的功能。

2）正面案例：

// 使用策略模式扩展行为
class Logger {
  log(message, loggerStrategy) {
    loggerStrategy(message);
  }
}

// 定义策略（扩展）
const consoleStrategy = (msg) => console.log(msg);
const fileStrategy = (msg) => writeToFile(msg);
const httpStrategy = (msg) => fetch(\'/log\', { body: msg }); // 添加新的记录器而无需修改 Logger 类

// 使用：
const logger = new Logger();
logger.log(\"Error!\", httpStrategy); // 无需修改 Logger

这里通过使用策略模式，Logger类的log方法接收一个策略函数loggerStrategy。当我们想要新增记录日志的方式时，只需要定义一个新的策略函数就行，完全不用修改Logger类本身的代码。这样既实现了功能扩展，又保证了原有代码的稳定性。

里氏替换原则（LSP）：保证子类的可替代性

里氏替换原则要求子类必须能够替换它们的父类，并且不会影响程序的正常运行。也就是说，在使用父类的地方，都可以安全地用子类来代替。

1）反面案例：

class Rectangle {
  setWidth(w) { this.width = w }
  setHeight(h) { this.height = h }
}

class Square extends Rectangle {
  setSize(size) { // 违反 LSP
    this.width = size;
    this.height = size;
  }
}

function resizeShape(shape) {
  shape.setWidth(10);
  shape.setHeight(5); // 对于 Square 来说会出问题
}

在这个例子中，Square类继承自Rectangle类，但Square类中定义的setSize方法破坏了里氏替换原则。当resizeShape函数对一个Square对象进行操作时，就会出现不符合预期的结果，因为Square的宽高是相等的，不能像普通Rectangle那样分别设置宽高。

2）正面案例：

class Shape {
  area() { /* 抽象 */ }
}

class Rectangle extends Shape { /* 实现 area */ }
class Square extends Shape { /* 实现 area */ }

改进后，Rectangle和Square都继承自抽象的Shape类，并且都实现了area方法。这样在使用Shape类的地方，无论是Rectangle还是Square都可以正常替换，不会出现问题。

接口隔离原则（ISP）：拒绝臃肿，只取所需

接口隔离原则强调客户端不应该依赖那些它们根本用不到的接口。这就好比我们去超市买东西，只拿自己需要的，没必要把超市所有的商品都搬回家。

1）反面案例：

class Worker {
  work() { /* ... */ }
  eat() { /* ... */ }
}

// Robot 被迫实现 eat()
class Robot extends Worker {
  eat() { throw Error(\"Robots don\'t eat!\"); }
}

在这个例子中，Worker类定义了work和eat两个方法，而Robot类继承自Worker类，但机器人根本不需要eat这个功能，却不得不实现它，这就导致了代码的不合理和臃肿。

2）正面案例：

class Workable {
  work() { /* 接口 */ }
}

class Eatable {
  eat() { /* 接口 */ }
}

class Human implements Workable, Eatable { /* ... */ }
class Robot implements Workable { /* ... */ }

改进后，把work和eat两个功能分别定义在不同的接口中。Human类实现了Workable和Eatable接口，因为人既会工作也会吃饭；而Robot类只实现Workable接口，因为机器人只需要工作，这样代码就简洁合理多了。

依赖倒置原则（DIP）：依赖抽象，远离具体

依赖倒置原则告诉我们，在代码中应该依赖抽象（比如接口、抽象类），而不是依赖具体的实现类。这样可以降低代码之间的耦合度，提高代码的可维护性和可测试性。

1）反面案例：

class MySQLDatabase {
  save(data) { /* MySQL 特定 */ }
}

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

在这段代码里，UserService类直接依赖了MySQLDatabase这个具体的数据库实现类。如果后续要更换数据库，比如从MySQL换成MongoDB，就需要大量修改UserService类的代码，这显然不是我们想要的。

2）正面案例：

class Database {
  save(data) { /* 抽象 */ }
}

class MySQLDatabase extends Database { /* ... */ }
class MongoDB extends Database { /* ... */ }

class UserService {
  constructor(database) {
    this.db = database; // 注入依赖
  }
}

改进后，先定义了一个抽象的Database类，MySQLDatabase和MongoDB都继承自这个抽象类。UserService类通过构造函数注入Database类型的依赖，这样就和具体的数据库实现解耦了。如果要更换数据库，只需要更换注入的具体实现类就行，UserService类本身的代码基本不需要修改。