SOLID之SRP

单一职责原则 SRP,single responsibility principle

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

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

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

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

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


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

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

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

单一

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

狭义:

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

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

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

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

广义:

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

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

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

职责

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

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

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

朱兴生 wechat
最新文章尽在微信公众号『码农戏码』