关于javascript:JavaScript-中的-SOLID-原则一S代表什么

1次阅读

共计 2027 个字符，预计需要花费 6 分钟才能阅读完成。

你可能曾经理解过一些设计准则或者设计模式，本文次要渐进的解说了 SOLID 准则：

不应用 SOLID 是怎么编写代码的，存在什么问题？
应该应用 SOLID 中的哪个准则？
应用 SOLID 咱们应该如何对代码进行批改？

置信比照和沉迷式的示例会让你更容易了解 SOLID 准则，以及如何利用到代码实际中。

这是 SOLID 的第一篇翻译文章(原文一共五篇)，来自 hackernoon，作者是 serhiirubets，欢送继续关注。

在本文中，咱们将探讨什么是 SOLID 准则，为什么咱们应该应用他们和如何在 JavaScript 中应用他们。

SOLID 是 Robert C. Martin 的前五个面向对象设计准则的首字母缩写词。这些准则的目标是：让你的代码、架构更具可读性、可维护性、灵活性。

繁多职责准则(Single Responsibility Principle)

S – 繁多职责准则 一个实体应该解决一项特定工作。

当咱们的类 (函数、组件、服务) 做很多货色，那就会失去一堆关联的代码，如果改变一处可能会影响到其余中央，这些中央其实没有相关性。而且这个类很难保护，新增的代码改变可能会影响到其余中央，造成不可预知的问题。可读性也会很差，如果这个文件代码量很大，了解起来会异样苦楚。

咱们先来看一下没有应用繁多准则的示例：

class Movie {constructor(options){
    this.name = options.name;
    this.description = options.description;
    this.rating = options.rating;
  }
  changeDescription (newDescription) {this.description = newDescription;}
  changeRat ing (newRating) {this.rating = newRating;}
  saveUserToFile() []
  saveUserToDB() []
}

咱们写了一个简略的类 Movie，并提供了一个办法来批改形容、评级、保留电影到数据库或文件系统。看上去没有什么问题，然而思考到将来可能新增的扩大：

咱们可能会增加一些新的办法，比方：从数据库中获取一部电影的数据，在保留电影的时候进行验证，从数据库中删除电影等，咱们的类将会是“God Object”反模式(“上帝模式”: 一个类做了太多事件，或者把很多不相干的逻辑放到了一个类中来实现)。
咱们可能会批改一个办法，很大概率上会影响其余中央。
反复的代码。咱们可能还有其余的类，比方 Audio 或 Picture，这些类可能也会应用相似的数据库、文件系统、和验证办法，咱们应该怎么做呢？第一个想法可能是在每个类 (Audio、Picture、Movie) 中去写同样的办法，这刚好就是第二个反模式“DRY”(Don’t repeat yourself.)。而且如果零碎中包含很多类，每个类都有本人的办法，当做调整的时候大概率会遗记批改某个类的逻辑，这就会造成问题。
更难了解和保护。

那么如何重写代码逻辑来解决这些问题？咱们应该先想起应用“繁多职责准则”，“繁多职责”实际上就是“一个实体解决一个特定的工作”。那在“Movie”类中有什么工作呢？

解决电影数据
操作数据库
操作文件系统

那咱们就能够创立 3 个类：Movie、DB、FileSystem。

class Movie {constructor(options) {
        this.name = options.name ;
        this.description = options.description; 
        this.rating = options.rating;
    }
    changeDescription(newDescription) {this.description = newDescription;}
    changeRat ing (newRating) {this.rating = newRating;}
}

class DB {constructor(options) {
        this.url = options.url;
        this.loginname = options.loginname;
        this.password = options.password;
    }
    save(data) {}
    delete(id) {}}

class FileSystem {constructor(options) {this.name = options.name;}
    save(data) {}
    delete(data) {}}

当初咱们有了 3 个独立的类，每个类只用来实现一个特定的工作。这样拆散有以下益处：