文章首发在公众号“混沌前端”
你可能已经了解过一些设计原则或者设计模式，本文主要渐进的讲解了SOLID原则：
- 不使用SOLID是怎么编写代码的，存在什么问题？
- 应该使用SOLID中的哪个原则？
- 使用SOLID我们应该如何对代码进行修改？
相信对比和沉浸式的示例会让你更容易理解SOLID原则，以及如何应用到代码实践中。
是SOLID的第一篇翻译文章(原文一共五篇)，来自hackernoon，作者是serhiirubets，欢迎持续关注。
在本文中，我们将讨论什么是 SOLID 原则，为什么我们应该使用他们和如何在JavaScript中使用他们。
什么是SOLID
SOLID 是 Robert C. Martin 的前五个面向对象设计原则的首字母缩写词。 这些原则的目的是：让你的代码、架构更具可读性、可维护性、灵活性。
单一职责原则(Single Responsibility Principle)
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，并提供了一个方法来修改描述、评级、保存电影到数据库或文件系统。看上去没有什么问题，但是考虑到未来可能新增的扩展：
- 我们可能会添加一些新的方法，比如：从数据库中获取一部电影的数据，在保存电影的时候进行验证，从数据库中删除电影等，我们的类将会是“God Object”反模式(“上帝模式”:一个类做了太多事情，或者把很多不相关的逻辑放到了一个类中来完成)。
- 我们可能会修改一个方法，很大概率上会影响其他地方。
- 重复的代码。我们可能还有其他的类，比如Audio或Picture，这些类可能也会使用类似的数据库、文件系统、和验证方法，我们应该怎么做呢？第一个想法可能是在每个类(Audio、Picture、Movie)中去写同样的方法，这刚好就是第二个反模式“DRY”(Don't repeat yourself.)。而且如果系统中包含很多类，每个类都有自己的方法，当做调整的时候大概率会忘记修改某个类的逻辑，这就会造成问题。
- 更难理解和维护。
那么如何重写代码逻辑来解决这些问题？我们应该先想起使用“单一职责原则”，“单一职责”实际上就是“一个实体解决一个特定的任务”。那再“Movie”类中有什么任务呢？
- 处理电影数据
- 操作数据库
- 操作文件系统
那我们就可以创建3个类：Movie、DB、FileSystem。
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;
}
}
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。
- 代码可读性更好，逻辑更简单。
- 没有了“God Object”
开闭原则（Open-Closed Principle）
O - 开闭原则。实体(类、模块、方法、文件等)应该对扩展开放，对修改关闭。从定义上很难理解，来看几个例子：
假设：我们有几个不同的形状，圆形、方向、三角形，需要计算他们的面积总和。如何解决呢？
没什么难的，让我们为每个形状创建一个类，每个类有不同的字段：大小、高度、宽度、半径和类型字段。当计算每个形状的面积时，我们使用类型字段来区分。
classSquare{
constructor(size){
this.size=size;
this.type='square' ;
}
}
classCircle{
constructor(radius) {
this.radius=radius;
this.type='circle' ;
}
}
classRect{
constructor(width, height) {
this.width=width
this.height=height;
this.type='rect' ;
}
}
我们再创建一个函数，来计算面积。
functiongetTotalAreas (shapes){
returnshapes.reduce((total, shape) =>{
if (shape.type=='square') {
total+=shape.size*shape.size;
}elseif (shape.type='circle') {
total+=Math.PI*shape.radius;
}elseif (shape. type==' rect') {
total+=shape.width*shape.height;
}
returntotal;
}, 0);
}
getTotalAreas([
newSquare(5),
newCircle(4),
newRect(7,14)
]);
似乎看起来并没有什么问题，但是想象一下，如果我们想添加另一个形状(原型、椭圆、菱形)，我们应该怎么做？我们需要为他们中的每一个创建一个新的类，定义类型并在getTotalAreas中添加新的if/else。
注意：
O - 开闭原则。让我们再重复一遍：这个原则是指：实体(类、模块、方法等)应该对扩展开放，对修改关闭。
在getTotalAreas中，每次添加新的形状都需要进行修改。这不符合开闭原则，我们需要做什么调整？
我们需要在每个类中创建getArea方法(类型字段已经不再需要，已被删除)。
classSquare {
constructor(size) {
this.size=size;
}
getArea() {
returnthis.size*this.size;
}
}
classCircle {
constructor(radius) {
this.radius=radius;
}
getArea() {
returnMath.PI* (this.radius*this.radius);
}
}
classRect {
constructor(width, height) {
this.width=width;
this.height=height;
}
getArea() {
returnthis.width*this.height;
}
}
functiongetTotalAreas (shapes) {
returnshapes. reduce((total, shape) => {
returntotal+shape. getArea();
},0)
}
getTotalAreas([
newSquare(5),
newCircle(4),
newRect(7,14)
]);
现在我们已经遵循了开闭原则，当我们要添加另一个形状，比如三角形，我们会创建一个Triangle类(对扩展开放)，定义一个getArea方法，仅此而已。我们不需要修改getTotalAreas方法(对修改关闭)，只需要在调用getTotalAreas时向其数组增加一个参数。
我们再来看一个更实际的例子, 假设客户端接收一个指定格式的错误验证消息：
constresponse= {
errors: {
name: ['The name field should be more than 2 letters', 'The name field should not contains numbers'] ,
email: ['The email field is required'],
phone: ['User with provided phone exist']
}
}
想象一下，服务端使用了不同的服务来验证，可能是我们自己的服务，也可能是返回不同格式错误的外部服务。
让我们使用尽可能用简单的示例来模拟错误：
consterrorFromFacebook='Bad credentials' ;
consterrorFromTwitter= ['Bad credentials'];
consterrorFromGoogle= { error: 'Bad credentials' }
functionrequestToFacebook() {
return {
type: 'facebook',
error: errorFromFacebook
}
}
functionrequestToTwitter() {
return {
type: 'twitter',
error: errorFromTwitter
}
}
functionrequestToGoogle() {
return {
type: 'google',
error: errorFromGoogle
}
}
我们来把错误转换成客户端所需要的格式：
functiongetErrors() {
consterrorsList= [requestToFacebook(), requestToTwitter(), requestToGoogle()];
consterrors=errorsList.reduce((res, error) => {
if (error.type==' facebook') {
res.facebookUser= [error.error]
}
if (error.type=='twitter') {
res.twitterUser=error.error;
}
if (error.type=='google') {
res.googleUser= [error.error];
}
returnres;
},[]);
return { errors };
}
console.log(getErrors());
我们就得到了客户端所期望的结果：
{
errors: {
facebookUser:['Bad credentials'],
twitterUser:['Bad credentials'],
googleUser:['Bad credentials']
}
}
但是，还是同样的问题，我们没有遵循开闭原则，当我们需要从外部服务添加一个新的验证时，我们就需要修改getErrors方法，添加新的if/else逻辑。
怎么解决这个问题呢？一个可行的解决方案是：我们可以创建一些通用的错误验证类，并在其中定义一些通用的逻辑。我们就可以为每个错误创建一个我们自己的类(FaceBookValidationError，GoogleValidationError)。
在每个类中，我们可以指定方法，像getErrors或TransformErrors,每个validationError类都应该遵循这个规则。
const errorFromFacebook =' Bad credentials ' ;
const errorFromTwitter = ['Bad credentials'];
const errorFromGoogle = {error: ' Bad credentials'}
class ValidationError {
constructor(error) {
this.error = error;
}
getErrors() {}
}
class FacebookValidationError extends ValidationError {
getErrors() {
return { key: ' facebookUser', text:[this.error] };
}
}
class TwitterValidationError extends ValidationError {
getErrors() {
return {
key: ' twitterUser',
text: this.error
}
}
}
class GoogleValidationError extends ValidationError {
getErrors() {
return { key: ' googleUser', text: [this.error.error] }
}
}
我们来在Mock的函数中使用这个错误验证类，修改getErrors函数：
function requestToFacebook() {
return new FacebookValidationError(errorFromFacebook)
}
function requestToTwitter() {
return new TwitterValidationError(errorFromTwitter)
}
function requestToGoogle() {
return new GoogleValidationError(errorFromGoogle)
}
function getErrors (errorsList) {
const errors = errorsList.reduce((res, item) => {
const error = item.getErrors();
res[error.key] = error.text
return res ;
}, {});
return {errors}
}
console.log(getErrors([requestToFacebook(), requestToTwitter(), requestToGoogle()]));
可以看到，在getErrors函数接收errorList作为参数，而不是在函数中进行硬编码。运行结果是一样的，但是我们遵循了开闭原则，当新增一个错误时：我们可以为这个错误创建一个新的验证类并且指定getErrors方法(对扩展开放)，getErrors可以帮我们把外部服务返回的信息转换成我们需要的格式。我们在通用的getErrors方法中来调用错误类的getErrors，无需进行其他修改(对修改关闭)。
推荐阅读：
