JavaScript中的SOLID设计原则讲解

2024/12/14 0:03:12

本文主要是介绍JavaScript中的SOLID设计原则讲解，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

面向对象编程（OOP）范式引入了诸如继承、多态、抽象和封装等关键编程概念。OOP很快成为了一个被广泛接受的编程范式，并被多种语言所实现，例如Java、C++、C#、JavaScript等。随着时间的推移，OOP系统变得越来越复杂，但其软件仍然具有较强的抗变化性。为了提高软件的扩展性和减少代码僵化，Robert C. Martin（也就是大家熟知的Uncle Bob）在21世纪初提出了即SOLID原则。

SOLID 是一个首字母缩略词，代表一组原则——单一职责原则、开闭原则（OCP）、里氏替换原则（LSP）、接口隔离原则和依赖倒置原则（DIP）——这些原则帮助软件工程师设计和编写更易维护、可扩展和灵活的代码。其目的是以提高面向对象编程（OOP）风格的软件开发质量为目标。

这篇文章中，我们将深入了解SOLID的所有原则，并通过使用最受欢迎的web编程语言之一JavaScript来展示它们是如何实现的。

单一职责（SRP）

在SOLID中，'S' 代表单一职责原则，也就是一个类或模块最好只做一件事情。

简单来说，一个类应该只有一个职责，即只有一个变更的理由。如果一个类负责多个功能，那么在不干扰其他功能的情况下更新某项功能会变得很麻烦。这种复杂性可能会导致软件性能出现问题。为了避免这些问题，我们应该尽量编写模块化软件，将各个关注点分开。

如果一个类承担太多责任或功能，修改起来就会变得很麻烦。通过遵循单一职责原则，我们可以写出更模块化、更易于维护且不易出错的代码。比如说，一个人的模型：

    class Person {
        constructor(name, age, height, country){
          this.name = name
          this.age = age
          this.height = height
          this.country = country
      }
      getPersonCountry(){
        console.log("您的国家是: " + this.country)    
      }
      greetPerson(){
        console.log("嗨 " + this.name)
      }
      static calculateAge(dob) { 
        const today = new Date(); 
        const birthDate = new Date(dob);

        let age = today.getFullYear() - birthDate.getFullYear(); 
        const monthDiff = today.getMonth() - birthDate.getMonth();

        if (monthDiff < 0 || (monthDiff === 0 && today.getDate() < birthDate.getDate())) { 
          age--; 
        }
        return age; 
      } 
    }

全屏退出全屏

上面的代码看起来没有问题，对吧？其实不然，这段示例代码违反了单一责任原则（Single Responsibility Principle）。Person 类不仅作为创建其他 Person 实例的唯一模型，还承担了如 calculateAge，greetPerson，和 getPersonCountry 等多种职责等。

这些由 Person 类处理的额外职责让仅改变代码的某一方面变得很困难。比如，当你想要重构 calculateAge 时，你可能也需要重构整个 Person 类。根据我们代码库的结构，重构代码不会引发错误可能很困难。

让我们尝试修正这个错误。可以把不同的责任划分到不同的类里，如下。

    class Person {
        constructor(name, dateOfBirth, height, country){
          this.name = name
          this.dateOfBirth = dateOfBirth
          this.height = height
          this.country = country
      }
    }

    class PersonUtils {
      static calculateAge(dob) { 
        const today = new Date(); 
        const birthDate = new Date(dob);

        let age = today.getFullYear() - birthDate.getFullYear(); 
        const monthDiff = today.getMonth() - birthDate.getMonth();

        if(monthDiff < 0 || (monthDiff === 0 && today.getDate() < birthDate.getDate())) { 
          age--; 
        }
        return age; 
      } 
    }

    const person = new Person("John", new Date(1994, 11, 23), "6英尺", "USA"); 
    console.log("年龄是：" + PersonUtils.calculateAge(person.dateOfBirth));

    class PersonService {
      getPersonCountry(){
        console.log("控制台输出这个人的国籍")    
      }
      greetPerson(){
        console.log("控制台输出问候语加上名字")
      }
    }

全屏，退出全屏

如上面的示例代码所示，我们已经分隔了各自的职责。现在的 Person 类就是一个模型，可以用来创建新的人员实例。而 PersonUtils 类只有一个任务——计算一个人的年龄差。PersonService 类负责问候，并显示每个人的国籍。

如果我们愿意的话，我们还可以进一步减少这个流程的复杂度。遵循单一职责原则（SRP），，我们希望将一个类的责任分解到最细，这样在出现问题时，，重构和调试会更加简单。

通过将功能拆分到单独的类中，我们遵守单一职责原则（每个类只负责一个特定的功能），确保每个类都负责应用程序的特定部分。

在我们继续讨论下一个原则之前，值得注意的是，遵循单一责任原则（SRP）并不意味着每个类必须要严格地只包含一个方法或功能。

然而，遵循单一职责原则意味着我们应该有意地将功能分配给类。一个类所做的一切应该在各个方面都有紧密的关联。我们一定要避免让多个类分散到各处，并且我们必须竭力避免代码库中出现臃肿的类。

开闭原则（OCP）

开放封闭原则表明，软件组件（类、函数、模块等）应该对扩展开放，对修改封闭。我知道你可能觉得这个想法乍一听似乎有点矛盾。但开放封闭原则实际上只是要求软件设计成无需修改源代码即可扩展。

OCP（开放封闭原则）对于维护大型代码库非常重要，因为这条指导方针使您能够几乎无风险地添加新功能。面对新的需求时，您应该通过添加新组件来扩展相关类，而不是直接修改现有的类或模块。在扩展过程中，确保新组件不会引入任何错误。

我们可以在 JavaScript 中利用 ES6+ 类的继承功能来实现 OC 原则。

以下代码示例展示了如何使用ES6+类关键字在JavaScript中实现开闭性原则：

    class Rectangle { 
      constructor(width, height) {
        this.width = width; 
        this.height = height; 
      } 
      // 计算矩形的面积
      area() { 
        return this.width * this.height; 
      } 
    } 

    class ShapeProcessor { 
        // 计算形状的面积
        calculateArea(shape) { 
          if (shape instanceof Rectangle) { 
            return shape.area(); 
          } 
        }
    }  
    // 创建一个矩形实例
    const rectangle = new Rectangle(10, 20); 
    // 创建一个ShapeProcessor实例
    const shapeProcessor = new ShapeProcessor(); 
    // 输出矩形的面积，预期输出为200
    console.log(shapeProcessor.calculateArea(rectangle)); // 输出应为 200

全屏按键退出全屏
按 [按键] 退出

上面的代码确实有效，但只能计算矩形的面积。现在假设我们需要计算圆的面积。我们可能需要修改 shapeProcessor 类来应对这个需求。然而，根据 JavaScript ES6+ 的标准，我们可以在不修改 shapeProcessor 类的前提下，扩展其功能以计算新形状的面积。

我们可以这样来干。

    class Shape {
      area() {
        console.log("请子类重写此方法以计算面积");
      }
    }

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

      area() {
        return this.width 乘以 this.height;
      }
    }

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

      area() {
        return Math.PI 乘以 this.radius 的平方;
      }
    }

    class ShapeProcessor {
      calculateArea(shape) {
        return shape.计算面积();
      }
    }

    创建一个矩形对象const rectangle = new Rectangle(20, 10);

    创建一个圆对象const circle = new Circle(2);

    const shapeProcessor = new ShapeProcessor();

    打印矩形的面积console.log(shapeProcessor.calculateArea(rectangle));

    打印圆的面积console.log(shapeProcessor.calculateArea(circle));

全屏模式, 退出全屏

在上述代码片段中，我们通过使用 extends 关键字扩展了 Shape 类。在每个子类中，我们重写了 area() 方法。遵循这一原则，我们可以继续添加更多形状并处理它们的面积，而无需更改 ShapeProcessor 类的实现。

为什么OCP（开放计算项目）很重要？

减少 bugs：OCP 通过避免修改系统来帮助在大规模代码库中减少 bugs。
促进软件适应性：OCP 还提高了增加新功能的便捷性，而无需破坏或修改源代码。
测试新功能：OCP 促进了扩展而非修改，使得新功能可以作为一个整体测试而不影响整个代码库。

里氏替换原则（Liskov 替换原则）

里科夫替换原则指出，一个子类的对象应该能够替换一个父类的对象，而不导致代码崩溃。让我们用一个例子来说明这个原则是如何运作的：如果 L 是 P 的子类，那么 L 的对象应能替换 P 的对象而不破坏系统。这仅仅表示子类应该能够以不破坏系统的方式重写父类的方法。

实际上，Liskov 替换原则确保这些条件得到遵守。

子类应该重写父类的方法而不破坏代码
子类不应偏离或改变父类的行为，这意味着子类只能添加功能，而不能修改或移除父类的功能
与父类实例一起工作的代码仍然应该能与子类实例一起工作，而无需知道类已经改变

是时候用JavaScript代码示例来说明里氏替换原则了。下面来看一下

    class Vehicle {
      启动引擎(){
        console.log("引擎启动了!");
      }
    }

    class Car extends Vehicle {
      // 可以调用父类的启动引擎方法并实现具体的汽车启动逻辑
    }
    class Bicycle extends Vehicle {
      启动引擎(){
        throw new Error("自行车实际上没有引擎");
      }
    }

    const 我的车 = new Car();
    const 我的自行车 = new Bicycle();

    我的车.启动引擎();
    我的自行车.启动引擎();

全屏显示退出全屏

在上面的代码示例中，我们创建了两个子类（自行车和汽车）和一个超类（车辆）。在这里，我们在车辆中实现了一个名为 OnEngine 的方法。

LSP的一个核心条件是子类应该能够重写父类的方法而不破坏代码。考虑到这一点，让我们看看我们刚刚看到的代码示例是如何违反Liskov替换原则（LSP）的。实际上，一辆Car有引擎并且可以发动引擎，但从技术角度来说，一辆自行车没有引擎，因此不能发动引擎。因此，Bicycle不能在不破坏代码的情况下重写Vehicle类中的OnEngine方法。

我们现在已经确定了违反里氏替换原则的代码部分，如下所示。Car 类可以覆盖超类中的 OnEngine 功能，并以一种不同于其他车辆（如飞机）的方式来实现它，从而不会导致代码出错。所以，Car 类满足里氏替换原则。

在下面的代码示例中，我们将展示如何编写符合Liskov替换原则的代码：

    class Vehicle { 
      move() {
       console.log("打印车辆移动信息。"); 
      } 
    }

全屏模式，进退自如

这里有一个基本的 Vehicle 类示例，它具有一般功能，即 move 方法。人们普遍认为所有车辆都可以移动，只是它们通过不同的机制来实现这一功能。我们将通过重写 move() 方法来展示不同的车辆，例如 Car 如何具体移动，以此来展示 LSP 原则。

为此目的，我们将创建一个Car类，该类继承自Vehicle类并重写move方法以实现汽车特有的移动方式，如下所示：

    class Car extends 车辆 {
      移动(){
        console.log("汽车正在用四个轮子行驶")
      }
    }

全屏显示退出全屏

我们还可以在另一个子类中实现移动方法，比如一架飞机。

我们可以，这样来做：

    class Airplane extends Vehicle {
        move(){
          console.log("飞机在飞行...");
      }
    }

全屏模式退出全屏

在上述两个例子中，我们展示了关键概念，比如继承和方法覆盖。

注释：允许子类实现父类中已定义方法的编程特性被称为方法重写功能。

咱们先收拾一下，把所有的东西整理在一起，就这样：

    class Vehicle { 
      move() {
       console.log("车辆在移动。"); 
      } 
    }

    class Car extends Vehicle {
      move(){
        console.log("汽车在四个轮子上行驶。")
      }
      getSeatCapacity(){
      }
    }

    class Airplane extends Vehicle {
        move(){
          console.log("飞机在飞行...")
      }
    }

    const car = new Car();
    const airplane = new Airplane();

    car.move() // 输出: 汽车在四个轮子上行驶

进入全屏退出全屏

我们目前有两个子类继承并重写了一个功能，以满足各自的需求。这种新的实现方式不会破坏现有代码。

接口隔离规范 (接口隔离原则)

接口隔离原则表明，没有任何客户端应该被迫依赖于不必要的接口。其目的是让我们创建更小且更具体的接口，与特定客户端相关，而不是应该有庞大的单一接口。而是应该有更小且具体的接口，以避免迫使客户端实现不需要的方法。

保持我们的接口简洁可以使代码库更易于调试、维护、测试和扩展。如果没有 ISP，大型接口中的一处变化可能会迫使代码库中未受影响的部分也进行修改，这通常需要我们进行代码重构，根据代码库的规模，这种任务通常会非常棘手。

与基于C的编程语言（如Java）不同，JavaScript没有内置的interface支持。但是，在JavaScript中，也可以通过一些技术来实现interface。

编程语言中的接口是一组方法定义，类必须实现这些定义。

在 JavaScript 中，你可以通过定义一个包含方法签名和函数名称的对象来创建接口。

const InterfaceA = {
  方法: function (){}
}

Adjusted to expert suggestions:

const InterfaceA = {
  方法: function (){}
}

Corrected according to the suggestions:

const InterfaceA = {
  方法: function (){}
}

Final Adjustment:

const InterfaceA = {
  方法: function (){}
}

Final Corrected Version:

const InterfaceA = {
  方法: function (){}
}

Final Corrected and Adjusted Version:

const InterfaceA = {
  方法: function (){}
}

Final Correct Translation:

const InterfaceA = {
  方法: function (){}
}