持续创作，加快生长！这是我参与「日新方案 10 月更文应战」的第3天，点击查看活动详情

规划准则系列文章

单一责任准则|规划准则 – ()

开闭准则|规划准则 – ()

里氏替换准则|规划准则 – ()

接口隔离准则|规划准则 – ()

依靠回转准则|规划准则 – ()

迪米特准则|规划准则 – ()

六大准则之外的规划准则|规划准则 – ()

前置知识

  • 有项目编写阅历
  • 听说过规划形式

前言

咱们经常有听过规划形式，也了解规划形式对项目和代码规划逻辑的重要性。可是你是否知道，所有的规划形式，无论是经典的23种规划形式之内，或许23种之外的，其实他们都是根据最基本的6种规划准则打开的。了解6种规划准则，咱们能够从本源更好的了解23种经典的规划形式。甚至待到你的经历登峰造极之时，能够创造出自己的一种规划形式。

本文带大家学习和了解第一种规划准则，单一责任准则

单一责任准则

界说：就一个类而言，应该仅有一个引起它改变的原因。应该只要一个责任。 每一个责任都是改变的一个轴线，假如一个类有一个以上的责任，这些责任就耦合在了一同。这会导致软弱的规划。当一个责任发生改变时，可能会影响其它的责任。别的，多个责任耦合在一同，会影响复用性。例如：要完结逻辑和界面的别离。

上文的界说源自百度，其意思简单来说为：一个类或许模块只承当一个责任

单一责任指的是到哪个程度的单一？

单一责任准则实践上很好了解，可是其边界咱们却难以断定。

那么，一个类完结一个事务功用是单一责任，仍是一个类完结一个事务功用中某个流程步骤的功用称之为单一责任？

一起单一责任描述的是类和模块，那么类能够被称之为模块吗？仍是说多个类才能祖成一个模块？咱们实践中的单一责任应该针对某个类，仍是针对多个类组成的模块呢？

要回答上述的这些问题，需求咱们对单一责任有更加深的了解。

事实上，关于 单一责任准则 这种较为难以界定实践边界的规矩，咱们对其的界说应该是随着事务的改变而改变的，其界说应该是动态化的。

当事务需求小的时分，咱们以为模块是类的抽象化表达，那么一个类能完结的一个功用块，咱们也称之为模块。那咱们的单一责任自然也是一个类而已。

当事务需求变大了，咱们抽取出多个类一同完结某个功用，那咱们以为这个功用触及到的类合起来完结的为一个模块。可是这个时分，单一责任并非就全指整个模块了，关于整个模块，单一责任的评判是该模块是否完结的是单一的一个大功用，没有去完结其他的功用。关于其间的类，咱们需求看是否包括其他事务范畴的操作，假如包括，且存在该范畴的事务，那么咱们应该把这些关于其他事务范畴的代码拆解出来，成为一个新的类；而假如包括，但现在不存在该范畴的事务，那这个类也能够为是足够单一的类了。

举个例子：

某个功用类中包括订单和地址的信息和操作

可是现在并不需求关于订单或许地址的功用，那么该功用类能够为是契合单一责任准则了

若是现在有触及订单和地址的事务，咱们就需求把订单和地址单独出来成为一个类，这姿态才算契合单一责任

所以说，单一责任的规模，取决于咱们的事务规模

所以咱们代码是否单一，都是根据当时的事务来说的，咱们要保护代码契合该准则，就需求不断地持续重构

咱们能够先写一个粗粒度的类，满意事务需求。随着事务的开展，假如粗粒度的类越来越巨大，代码越来越多，这个时分，咱们就能够将这个粗粒度的类，拆分红几个更细粒度的类。这便是所谓的持续重构

那么根据当时编程界的实践经历，咱们有哪些明晰的准则判别是否契合单一准则呢？

咱们能够从以下方面判别

类中的代码行数、函数或特点过多，会影响代码的可读性和可保护性，咱们就需求考虑对类进行拆分；

类依靠的其他类过多，或许依靠类的其他类过多，不契合高内聚、低耦合的规划思想，咱们就需求考虑对类进行拆分；

私有办法过多，咱们就要考虑能否将私有办法独立到新的类中，设置为 public 办法，供更多的类使用，从而进步代码的复用性；

比较难给类起一个适宜名字，很难用一个事务名词概括，或许只能用一些抽象的 Manager、Context 之类的词语来命名，这就说明类的责任界说得可能不够明晰；

类中大量的办法都是会集操作类中的某几个特点，比方，在 UserInfo 例子中，假如一半的办法都是在操作 address 信息，那就能够考虑将这几个特点和对应的办法拆分出来。

咱们规划的类越单一就必定越好吗？

实践上并非如此，单一的规模是有限度的，咱们将单一责任的规则过于细化的时分，想让每一个小功用都更单一时分，会适得其反，导致代码易用性遭到破坏。

咱们规划的时分，把一些其间功用相关性较大的类，为了单一责任，而把其拆开为多个类。反而导致代码内聚性和可保护性减低。

所以说，咱们是否要设置的更加单一，仍是要以实践的操作和功用来判别

不管是使用规划准则仍是规划形式，终究的意图仍是进步代码的可读性、可扩展性、复用性、可保护性等。咱们在考虑使用某一个规划准则是否合理的时分，也能够以此作为终究的考量规范

单一责任准则通过防止规划大而全的类，防止将不相关的功用耦合在一同，来进步类的内聚性。一起，类责任单一，类依靠的和被依靠的其他类也会变少，减少了代码的耦合性，以此来完结代码的高内聚、低耦合。可是，假如拆分得过细，实践上会适得其反，反倒会降低内聚性，也会影响代码的可保护性

参考

15 | 理论一：关于单一责任准则，怎么断定某个类的责任是否够“单一”？ (geekbang.org)

单一责任准则_百度百科 (baidu.com)