SOLID之SRP

单一职责原则 SRP，single responsibility principle

SRP是所有原则中最简单的之一，也是最难正确运用的之一，也是我们日常中最常用的一个

不管是编码，重构，甚至当下流行的微服务中

在很多团队的规范中，都会听到一条编码规范：一个方法不要超过x行代码

作为一群自命不凡的程序员，为什么在规范中却有如此一条格调不对称规范

主要问题就在于思维对SRP的缺失

微服务这个术语的一个问题是会将你的关注点错误地聚集在“微”上。它暗示服务应该非常小。很多团队在实施时，也是往小了去考虑，偏移了核心目标

微服务的目标是将精心设计的服务定义为能够由小团队开发的服务，并且交付时间最短，与其它团队协作最小。

理论上，团队可能只负责单一服务，因此服务绝对不是微小的

单一

从个人理解可以分为狭义与广义

狭义：

狭义只是从面向底层实现细节的设计原则

一个类而言，应该仅有一个引起它变化的原因

在日常中，在编写方法或者重构方法，也是以这个为原则，即确保一个函数只完成一个功能。

在将大方法重构成小方法时经常会用到这个原则

广义：

相对狭义，适用的范围相对大些，不再是一个类，一个方法，亦或是一个原因

任何一个软件模块都应该只对某一类行为者负责

“软件模块”不再只是一个类，可以是一组紧密相关的函数和数据结构,甚至一个独立应用服务

职责

什么是职责？如果一个类承担多于一个职责，那么引起它变化的原因就会有多个

在SRP中，职责定义为“变化的原因”，如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责

因此对于职责的定义需要结合具体业务，有时从感性上理解一个类的多个方法应该拆分，但如果应用程序的变化方式总是导致这几个职责同时变化，那么就不需要分离