SRP （单一职责原则）

这是我参与2022首次更文挑战的第18天，活动详情查看：2022首次更文挑战

概念

全名：Single responsibility principle 缩写：SRP

解决什么样的问题

• 实现高内聚，低耦合
• 提高代码可读性，复用性，可维护性。
• 降低变更引起的风险

将不同功能职责进行分离

A class should have only one reason to change

就一个类而言，应该仅有一个引起它变化的原因。应该只有一个职责

解析

• 思考1：需求会随着时间的增加而增加，假设有需求需要修改一个类，但是修改会影响到类的其他功能。

比如：

// 修改其他代码的时候，会不会影响登录功能
class User {
   function register() {
       // 其他代码
       // 登录逻辑代码
       // 其他代码
   }
}

或者修改成

// type传错，那么会影响用户其他功能
class User {
   function operate() {
       if (type == login) {
         // 登录操作
       } else if (type == register) {
         // 其他代码
       }
   }
}

这样会不会好一些 修改1：

// 修改其他代码的时候，会不会影响登录功能
class User {
   function register() {
       // 其他代码
   }
   function login(){
       // 登录操作
   }
}

那是不是可以这样 修改2:

// 修改其他代码的时候，会不会影响登录功能
class User {
}

class Register extends User {
  function register() {
       // 其他代码
   }
}

class Login extends User {
  function login() {
       // 其他代码
   }
}

等等还有很多很多类似的方法。

• 思考2：过度简化代码，创建具有一个功能的类，将单一职责原则发挥到了极致。这样我们必须注册过多的依赖项。拥有多个只包含一个函数的类到底有没有意义？

将不同行为者的职责进行分离。

比如：

// 修改其他代码的时候，会不会影响登录功能
class User {
 constructor() {
   name = '';
   address = '';
   id = '';
 }
 getName() {
 }
 getAddress() {
 }
 // 获取权限
 getAccess() {
 }
}

getAccess方法不属于用户(行为者)的职责。 比如access可以通过

class Access {
 // 获取用户权限
 getAccess(user) {
 }
}

总结

理解的比较简单，但是实际用起来比较难，难点在于如何多维度(不同的关注点去拆分类的职责)的去建立单一职责的类。