发布于 由admin

阐述 JavaScript 中 SOLID 原则在面向对象设计中的应用，例如单一职责原则 (SRP) 和依赖倒置原则 (DIP)。

好的，没问题。咱们开始今天的JavaScript SOLID 原则讲座！

大家好，我是今天的主讲人，人称“码农终结者”。今天咱们聊聊JavaScript中的SOLID原则，这玩意听起来高大上，其实就是一些让你代码更健壮、更容易维护的黄金法则。别担心，我会用最通俗易懂的语言，加上大量的代码示例，保证让你听完之后感觉“哇，原来是这样！”

什么是SOLID原则？

SOLID是面向对象设计中五个基本原则的首字母缩写，由Robert C. Martin（也就是“Uncle Bob”）提出。这五个原则分别是：

  • Single Responsibility Principle (SRP) – 单一职责原则
  • Open/Closed Principle (OCP) – 开放/封闭原则
  • Liskov Substitution Principle (LSP) – 里氏替换原则
  • Interface Segregation Principle (ISP) – 接口隔离原则
  • Dependency Inversion Principle (DIP) – 依赖倒置原则

这五个原则不是孤立存在的，它们相互关联，共同构建出高质量、可维护、可扩展的软件系统。

1. 单一职责原则 (SRP)

  • 原则描述：一个类应该只有一个引起它变化的原因。简单来说，一个类只负责一项职责。

  • 为什么重要？ 如果一个类承担了过多的职责，那么修改其中一个职责可能会影响到其他职责，导致意想不到的bug。而且，职责过多的类往往难以理解、测试和维护。

  • JavaScript 示例：

    反例：

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

  register() {
    // 注册用户
    console.log(`注册用户: ${this.name}, 邮箱: ${this.email}`);
  }

  validateEmail() {
    // 验证邮箱格式
    if (!this.email.includes('@')) {
      console.log('邮箱格式不正确');
      return false;
    }
    return true;
  }

  sendWelcomeEmail() {
    // 发送欢迎邮件
    console.log(`发送欢迎邮件给: ${this.email}`);
  }
}

const user = new User('张三', '[email protected]');
user.register();
user.validateEmail();
user.sendWelcomeEmail();

    这个 User 类承担了用户注册、邮箱验证和发送邮件三个职责，违反了 SRP。如果我们需要修改邮箱验证逻辑，就必须修改 User 类，这可能会影响到用户注册和发送邮件的功能。

    正例：

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

class UserRegister {
  register(user) {
    console.log(`注册用户: ${user.name}, 邮箱: ${user.email}`);
  }
}

class EmailValidator {
  validateEmail(email) {
    if (!email.includes('@')) {
      console.log('邮箱格式不正确');
      return false;
    }
    return true;
  }
}

class EmailService {
  sendWelcomeEmail(email) {
    console.log(`发送欢迎邮件给: ${email}`);
  }
}

const user = new User('张三', '[email protected]');
const userRegister = new UserRegister();
const emailValidator = new EmailValidator();
const emailService = new EmailService();

userRegister.register(user);
if (emailValidator.validateEmail(user.email)) {
  emailService.sendWelcomeEmail(user.email);
}

    我们将 User 类的职责拆分成了 UserRegister、EmailValidator 和 EmailService 三个类，每个类只负责一个职责。这样，修改其中一个类的逻辑不会影响到其他类。

2. 开放/封闭原则 (OCP)

  • 原则描述：软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。也就是说，在不修改原有代码的基础上，可以通过扩展来增加新的功能。

  • 为什么重要？ OCP 可以避免修改原有代码带来的风险，提高代码的稳定性和可维护性。

  • JavaScript 示例：

    反例：

    class Shape {
  constructor(type, width, height, radius) {
    this.type = type;
    this.width = width;
    this.height = height;
    this.radius = radius;
  }

  getArea() {
    if (this.type === 'rectangle') {
      return this.width * this.height;
    } else if (this.type === 'circle') {
      return Math.PI * this.radius * this.radius;
    }
    return 0;
  }
}

const rectangle = new Shape('rectangle', 10, 5);
const circle = new Shape('circle', null, null, 5);

console.log(`矩形面积: ${rectangle.getArea()}`);
console.log(`圆形面积: ${circle.getArea()}`);

    如果我们需要增加一个新的形状（比如三角形），就需要修改 Shape 类的 getArea 方法，违反了 OCP。

    正例：

    class Shape {
  getArea() {
    throw new Error('Method not implemented.');
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  getArea() {
    return Math.PI * this.radius * this.radius;
  }
}

class Triangle extends Shape {
    constructor(base, height) {
        super();
        this.base = base;
        this.height = height;
    }

    getArea() {
        return 0.5 * this.base * this.height;
    }
}

const rectangle = new Rectangle(10, 5);
const circle = new Circle(5);
const triangle = new Triangle(8, 6);

console.log(`矩形面积: ${rectangle.getArea()}`);
console.log(`圆形面积: ${circle.getArea()}`);
console.log(`三角形面积: ${triangle.getArea()}`);

    我们定义了一个抽象类 Shape，然后让 Rectangle 和 Circle 继承 Shape 类，并分别实现 getArea 方法。如果我们需要增加一个新的形状，只需要创建一个新的类继承 Shape 类，并实现 getArea 方法即可，而不需要修改 Shape 类。

3. 里氏替换原则 (LSP)

  • 原则描述：所有使用父类对象的地方，都应该能够透明地使用其子类对象。也就是说，子类应该能够替换父类，并且程序的行为不会发生错误。

  • 为什么重要？ LSP 保证了继承的正确性，避免了因为子类替换父类而导致的程序错误。

  • JavaScript 示例：

    反例：

    class Rectangle {
  constructor(width, height) {
    this.width = width;
    this.height = height;
  }

  setWidth(width) {
    this.width = width;
  }

  setHeight(height) {
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }
}

class Square extends Rectangle {
  constructor(size) {
    super(size, size);
    this.size = size;
  }

  setWidth(width) {
    this.width = width;
    this.height = width; // 保持宽高一致
  }

  setHeight(height) {
    this.width = height;
    this.height = height; // 保持宽高一致
  }
}

function increaseRectangleWidth(rectangle) {
  const originalHeight = rectangle.height;
  rectangle.setWidth(rectangle.width + 10);
  console.assert(rectangle.height === originalHeight); // 断言失败
}

const rectangle = new Rectangle(10, 5);
increaseRectangleWidth(rectangle); // 正常工作

const square = new Square(5);
increaseRectangleWidth(square); // 断言失败，square 的 height 也被修改了

    Square 类继承了 Rectangle 类，但是 Square 类的 setWidth 和 setHeight 方法会同时修改宽度和高度，这与 Rectangle 类的行为不一致，违反了 LSP。当我们将 Square 对象传递给 increaseRectangleWidth 函数时，程序的行为发生了错误。

    正例：

    class Shape {
  getArea() {
    throw new Error('Method not implemented.');
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  setWidth(width) {
    this.width = width;
  }

  setHeight(height) {
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }
}

class Square extends Shape {
  constructor(size) {
    super();
    this.size = size;
  }

  getArea() {
    return this.size * this.size;
  }
}

function printArea(shape) {
    console.log(`Area: ${shape.getArea()}`);
}

const rectangle = new Rectangle(10, 5);
const square = new Square(5);

printArea(rectangle);
printArea(square);

    我们将 Square 类和 Rectangle 类都继承自 Shape 类，并且 Square 类不再继承 Rectangle 类，避免了子类修改父类行为的问题。

4. 接口隔离原则 (ISP)

  • 原则描述：客户端不应该被迫依赖于它不使用的方法。也就是说，接口应该尽量小，只包含客户端需要的方法。

  • 为什么重要？ ISP 可以避免客户端依赖于不必要的方法，降低代码的耦合度，提高代码的灵活性。

  • JavaScript 示例：

    反例：

    class Machine {
  print() {
    throw new Error('Method not implemented.');
  }

  scan() {
    throw new Error('Method not implemented.');
  }

  fax() {
    throw new Error('Method not implemented.');
  }
}

class OldFashionedPrinter extends Machine {
  print() {
    console.log('Printing...');
  }

  scan() {
    // This printer can't scan, so we throw an error or leave it empty.
    throw new Error('Scanning not supported');
  }

  fax() {
      throw new Error('Faxing not supported');
  }
}

const printer = new OldFashionedPrinter();
printer.print(); // 正常工作
try {
    printer.scan(); // 抛出错误
} catch (e) {
    console.error(e.message);
}

    Machine 接口包含了 print、scan 和 fax 三个方法，但是 OldFashionedPrinter 类只实现了 print 方法，而 scan 和 fax 方法则抛出错误。这说明 OldFashionedPrinter 类被迫依赖于它不使用的方法，违反了 ISP。

    正例：

    class Printable {
  print() {
    throw new Error('Method not implemented.');
  }
}

class Scannable {
  scan() {
    throw new Error('Method not implemented.');
  }
}

class Faxable {
  fax() {
    throw new Error('Method not implemented.');
  }
}

class ModernPrinter extends Printable, Scannable, Faxable {
    print() {
        console.log('Printing...');
    }

    scan() {
        console.log('Scanning...');
    }

    fax() {
        console.log('Faxing...');
    }
}

class OldFashionedPrinter extends Printable {
  print() {
    console.log('Printing...');
  }
}

const printer = new OldFashionedPrinter();
printer.print();

const modernPrinter = new ModernPrinter();
modernPrinter.print();
modernPrinter.scan();
modernPrinter.fax();

    我们将 Machine 接口拆分成了 Printable、Scannable 和 Faxable 三个接口，OldFashionedPrinter 类只需要实现 Printable 接口即可，避免了依赖于不必要的方法。

5. 依赖倒置原则 (DIP)

  • 原则描述：

    • 高层模块不应该依赖于低层模块，两者都应该依赖于抽象。
    • 抽象不应该依赖于细节，细节应该依赖于抽象。

  • 为什么重要？ DIP 可以降低模块之间的耦合度，提高代码的灵活性和可测试性。

  • JavaScript 示例：

    反例：

    class LightBulb {
  turnOn() {
    console.log('LightBulb: Bulb turned on...');
  }

  turnOff() {
    console.log('LightBulb: Bulb turned off...');
  }
}

class Switch {
  constructor() {
    this.bulb = new LightBulb();
  }

  on() {
    this.bulb.turnOn();
  }

  off() {
    this.bulb.turnOff();
  }
}

const switchButton = new Switch();
switchButton.on();
switchButton.off();

    Switch 类直接依赖于 LightBulb 类，如果我们需要更换灯泡的类型，就需要修改 Switch 类，违反了 DIP。

    正例：

    class Switchable {
  turnOn() {
    throw new Error('Method not implemented.');
  }

  turnOff() {
    throw new Error('Method not implemented.');
  }
}

class LightBulb extends Switchable {
  turnOn() {
    console.log('LightBulb: Bulb turned on...');
  }

  turnOff() {
    console.log('LightBulb: Bulb turned off...');
  }
}

class Fan extends Switchable {
    turnOn() {
        console.log('Fan: Fan turned on...');
    }

    turnOff() {
        console.log('Fan: Fan turned off...');
    }
}

class Switch {
  constructor(device) {
    this.device = device;
  }

  on() {
    this.device.turnOn();
  }

  off() {
    this.device.turnOff();
  }
}

const bulb = new LightBulb();
const fan = new Fan();
const switchButtonBulb = new Switch(bulb);
const switchButtonFan = new Switch(fan);

switchButtonBulb.on();
switchButtonBulb.off();
switchButtonFan.on();
switchButtonFan.off();

    我们定义了一个抽象类 Switchable，然后让 LightBulb 类继承 Switchable 类。Switch 类依赖于 Switchable 接口，而不是具体的 LightBulb 类。这样，如果我们需要更换灯泡的类型，只需要创建一个新的类继承 Switchable 类，并将其实例传递给 Switch 类即可，而不需要修改 Switch 类。

总结

原则 描述 优点
单一职责原则 (SRP) 一个类应该只有一个引起它变化的原因。 提高类的内聚性，降低类的耦合度，提高代码的可读性、可维护性和可测试性。
开放/封闭原则 (OCP) 软件实体应该对扩展开放，对修改封闭。 提高代码的稳定性和可维护性，避免修改原有代码带来的风险。
里氏替换原则 (LSP) 所有使用父类对象的地方，都应该能够透明地使用其子类对象。 保证了继承的正确性，避免了因为子类替换父类而导致的程序错误。
接口隔离原则 (ISP) 客户端不应该被迫依赖于它不使用的方法。 避免客户端依赖于不必要的方法，降低代码的耦合度，提高代码的灵活性。
依赖倒置原则 (DIP) 高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。 降低模块之间的耦合度，提高代码的灵活性和可测试性。

SOLID原则是面向对象设计的基石，掌握这些原则可以帮助我们编写出高质量、可维护、可扩展的JavaScript代码。当然，SOLID原则并不是万能的，我们需要根据具体的场景来灵活应用。记住，代码不是写给机器看的，而是写给人看的，所以要尽量写出易于理解和维护的代码。

希望今天的讲座对你有所帮助！如果有任何问题，欢迎随时提问。下次再见！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注