单一职责原则 SRP，single responsibility principle
SRP是所有原则中最简单的之一，也是最难正确运用的之一，也是我们日常中最常用的一个
不管是编码，重构，甚至当下流行的微服务中
在很多团队的规范中，都会听到一条编码规范：一个方法不要超过x行代码
作为一群自命不凡的程序员，为什么在规范中却有如此一条格调不对称规范
主要问题就在于思维对SRP的缺失
微服务这个术语的一个问题是会将你的关注点错误地聚集在“微”上。它暗示服务应该非常小。很多团队在实施时，也是往小了去考虑，偏移了核心目标
微服务的目标是将精心设计的服务定义为能够由小团队开发的服务，并且交付时间最短，与其它团队协作最小。
理论上，团队可能只负责单一服务，因此服务绝对不是微小的
单一
从个人理解可以分为狭义与广义
狭义：
狭义只是从面向底层实现细节的设计原则
一个类而言，应该仅有一个引起它变化的原因
在日常中，在编写方法或者重构方法，也是以这个为原则，即确保一个函数只完成一个功能。
在将大方法重构成小方法时经常会用到这个原则
广义：
相对狭义，适用的范围相对大些，不再是一个类，一个方法，亦或是一个原因
任何一个软件模块都应该只对某一类行为者负责
“软件模块”不再只是一个类，可以是一组紧密相关的函数和数据结构,甚至一个独立应用服务
职责
什么是职责？如果一个类承担多于一个职责，那么引起它变化的原因就会有多个
在SRP中，职责定义为“变化的原因”，如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责
因此对于职责的定义需要结合具体业务，有时从感性上理解一个类的多个方法应该拆分，但如果应用程序的变化方式总是导致这几个职责同时变化，那么就不需要分离
欢迎关注【码农戏码】
