懂几个设计模式，只是花拳绣腿。掌握设计原则就才掌握了“道”。

设计你的系统，使得每个模块负责（响应）只满足一个业务功能需求。
Design your systems such that each module is responsible (responds to) the needs of just that one business function. (Robert C. Martin)

参考：https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

回答问题
1. 类单一职责判断可以通过评估其对外提供接口是否满足不断变化的业务和需求来确定！问自己，该类是否对其他类是"黑盒"！

2. 类行数多=属性多+方法多
属性多: 要考虑这些属性是不是对类来说是必须的，需要移除么？
方法多: 方法间复用情况，方法间有没有写重复代码？
如上如果觉得没有可以改进的余地，就可以认为类行数恰当！

3. 单一职责还可以应用到方法，模块，功能点上！

设计模式_15
# 作业：
单一职责也可以用于方法的编写，在维护多年的项目中，我们会看到一些非常“庞大”的方法，这些方法的功能比它的命名丰富很多，它是一次次地改成了这个样子。本来是一个职责单一的简单方法，由于需求的变化，可能是方法被调用太多(不敢改)，也可能是框架设计(不能改)导致只能在方法内部添加特殊业务的判断条件，这样下来，这个方法就变得难以理解且难以维护。

# 感想
同事们也常讨论单一职责的边界, 始终没有一致的结论。今天的内容也坚定了观点，业务的发展一定程序决定了耦合的边界。
我们学习前人总结的这些原则，目的是什么呢，我今天的感受是，系统性地降低工作量和出错概率。
- 降低工作量：我们要尽量保证，随着需求的增加，工作量的增加是线性的，而不是指数级的。据我了解，维护一些老代码的同学们，一直被产品同事质疑：就这么点功能，要做这么久吗？？？
- 降低出错概率：就像文中的序列化的例子，强行把序列化与反序列化方法拆开，会导致使用者需要花更多的时间来做一些同步的工作，如果文档不够清晰，或者阅读文档不够仔细，就会导致出错；有这样代码结构的系统，运行足够长的时间，一定会出更多的错误。

回答问题：
1.不好说，职责单一这东西比较主观。得看自己对抽象出来的类的主观定义是什么。准的捏不住，但还是要把控一下范围的。
2.码出高效给出了方法行数不超过50行的一个基准标注。而我实践下来很难写出超过50行的方法，这50行还包括了大量注释。

3.方法的职责单一，业务领域的能力要单一（边界清晰）。

提问：

1.以前不代码规范不行，就逼着自己多思考，多写注释。现在养成了写注释的洁癖，不写就很难受。请问大佬，这怎么办，需要戒掉吗。我除了dao层的crud和数据类的setget外，其余方法都会带上注释。

What

一个函数、类、模块只负责完成一个职责或者功能。

How

关于如何使用这个原则，不同的应用场景、需求背景、业务，对一个类职责是否单一，会有不同的判定结果。

这个说法其实很模糊，并没有多少实践上的指导意义。

定义中也存在令人迷惑的点，类由函数构成，模块由类构成（面向对象领域），如果每个函数职责单一，多个职责单一的功能函数组成一个类，那么这个类还算职责单一吗？

这里的区别在于看待职责单一的抽象维度不同，也称为职责颗粒度。

比如在函数的维度，在一个 getter 方法，只返回用户名，它是职责单一的；在用户类的维度，它还可以包含返回手机号的 getter 方法。

类也是有颗粒度的。以文中用户信息类为例，什么时候地址信息应该被作为单独类存在呢？我的结论是存在被复用的场景。

在初次设计时，可能并没有复用场景，那么都写在一个类里满足业务需求完全没问题。

但随着需求的发展，类中代码量膨胀，我们就需要根据复用性来对类进行拆分，此时单一职责原则可以作为一个指导思想。

过度使用单一职责

在设计时也不要过度使用单一职责原则，它会使得功能点不够内聚，增加维护成本。如果一个类，始终是作为整体被使用，即使它包含多种功能，放一起也可以。

当我们只想使用类的某一部分功能，又觉得其它功能鸡肋的时候，再考虑拆分也不迟。

Why

单一职责原则，是前辈在代码时间中的经验，将某一类经验抽象为这个名字。这个原则主要目的是为了，实现高内聚、低耦合、提高代码的复用性、可读性、可维护性。

项目初始阶段也是雄心勃勃，要把系统做出一个快速迭代、维护性高的系统，可是不断的需求变更导致开发任务过重，留给项目整体的思考和重构时间被严重压缩，最终导致项目的技术管理失控，再加上人员变动等原因，项目死亡的概率急剧上升，都是惨痛的教训。

《三体》中常伟思的父亲经常说的是：要多想。

共勉！