【推荐阅读】JavaScript 中的 SOLID 原则(一):“S”代表什么

你可能已经了解过一些设计原则或者设计模式,本文主要渐进的讲解了SOLID原则:

  • 不使用SOLID是怎么编写代码的,存在什么问题?

  • 应该使用SOLID中的哪个原则?

  • 使用SOLID我们应该如何对代码进行修改?

相信对比和沉浸式的示例会让你更容易理解SOLID原则,以及如何应用到代码实践中。

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

在本文中,我们将讨论什么是 SOLID 原则,为什么我们应该使用他们和如何在JavaScript中使用他们。

什么是SOLID

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个独立的类,每个类只用来完成一个特定的任务。这样分离有以下好处:

  • DRY原则。我们不需要再重复DB(文件)的逻辑,可以把任何实体(音乐、图片)传递给DB类,类会将他们保存到DB。

  • 代码可读性更好,逻辑更简单。

  • 没有了“God Object”

感谢阅读!欢迎关注微信公众号”混沌前端“,获取推送更新。

推荐阅读:

基于TypeScript理解程序设计的SOLID原则

clean-code-javascript: SOLID

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值