你可能知道一些设计原则或设计模式。本文主要讲解SOLID的原理：不使用SOLID如何写代码，存在哪些问题？应该使用SOLID中的哪个原则？我们应该如何使用SOLID修改代码？相信对比和身临其境的例子会让你更容易理解SOLID原则以及如何将其应用到代码实践中。这是SOLID的第一篇翻译文章（原创文章有五篇），来自hackernoon，作者serhiirubets，欢迎继续关注。在本文中，我们将讨论什么是SOLID原则，为什么要使用它们以及如何在JavaScript中使用它们。什么是SOLIDSOLID是RobertC.Martin的前五个面向对象设计原则的首字母缩写。这些原则的目的是使您的代码和架构更具可读性、可维护性和灵活性。单一职责原则（SingleResponsibilityPrinciple）S——单一职责原则一个实体应该解决一个特定的任务。当我们的类（函数、组件、服务）做了很多事情的时候，我们会得到一堆相关的代码。如果我们改变一个地方，它可能会影响到其他地方，这些地方实际上是不相关的。而且这个类很难维护，新的代码改动可能会影响其他地方，造成不可预知的问题。可读性也会很差。如果文件的代码量很大，理解起来会非常痛苦。我们先来看一个不使用单一原则的例子：classMovie{constructor(options){this.name=options.name;this.description=options.description;this.rating=options.rating;}changeDescription(newDescription){this.description=newDescription;}changeRating(newRating){this.rating=newRating;}saveUserToFile()[]saveUserToDB()[]}我们编写了一个简单的Movie类，并提供了一个方法来修改描述、评级、将电影保存到数据库或文件系统。貌似没有问题，但是考虑到以后可能的扩展：我们可能会增加一些新的方法，比如：从数据库中获取一个电影的数据，保存电影的时候校验，从数据库中删除电影等等，我们的类将是一个“上帝对象”反模式（“上帝模式”：一个类做了太多的事情，或者把很多不相关的逻辑放到一个类中去完成）。我们可能修改了一个方法，很大概率会影响其他地方。重复代码。我们可能还有其他的类，比如Audio或者Picture，它们也可能使用类似的数据库、文件系统和认证方式。我们应该怎么做？第一个想法可能是在每个类（Audio、Picture、Movie）中写相同的方法，这恰好是第二个反模式“DRY”（Don'trepeatyourself.）。而如果系统包含的类很多，每个类都有自己的方法，那么很有可能你在调整的时候忘记修改某个类的逻辑，就会出现问题。更难理解和维护。那么如何重写代码逻辑来解决这些问题呢？我们应该首先想到使用“单一职责原则”。“单一职责”实际上是“解决特定任务的实体”。那么“电影”课有哪些任务呢？处理电影数据操作数据库操作文件系统然后我们可以创建3个类：Movie、DB、FileSystem。电影类{构造函数（选项）{this.name=options.name;this.description=options.description;this.rating=options.rating;}changeDescription(newDescription){this.description=newDescription;}changeRating(newRating){this.rating=newRating;}}classDB{constructor(options){this.url=options.url;this.loginname=options.loginname;this.password=options.password;}save(data){}delete(id){}}classFileSystem{constructor(options){this.name=options.name;}save(data){}delete(data){}}现在我们有3个独立的类，每个类只完成一个特定的任务。这种分离有以下好处：DRY原则。我们不需要重复DB（文件）的逻辑，我们可以将任何实体（音乐，图片）传递给DB类，类将它们保存到DB中。代码可读性更强，逻辑更简单。没有“神物”，欢迎关注微信公众号《混沌前端》推荐阅读：基于TypeScript看懂程序设计的SOLID原理clean-code-javascript:SOLID
