SRP:单一职责原则

一、SRP:单一职责原则

1、概念：

软件系统中的每个元素（方法，类，模块，服务）只完成自己职责内的事情，将其他的事交给别人去做。

2、误区：职责的理解

错误理解：一个与该事情相关的事情
正确理解：一个职责是软件变化的一个原因

3、如何评价一段代码的优劣：

维护成本越低，越好。需求过来,模块改的越少越好，最好只改一个模块。

4、如何才能做到：

在今后不断变更的过程中，不断整理代码。将同一个变更原因的代码放在一起。修改的范围就变小了。

5、什么时候才能知道代码变化的原因：

在每次变更的时候，在每次不断的变更的时候。

6、场景举例：

①背景：有订单，支付，物流，商品信息四个微服务或者模块。

②场景Ⅰ：在下订单，支付，物流的时候都要读取商品的信息。

Ⅰ、问题：一旦商品信息发生变更，其他三个服务调用也要跟着变更，这是我们不像看到的。
Ⅱ、改造：这三部分需要变动的代码都是由于一个原因发生变化的代码。所以可以把这三块代码都放在商品服务里的一个类里，它的作用是维护商品信息变更引起的变化，用于统一维护。
Ⅲ、结果；其他三个模块只需要调用商品暴露的接口。

②场景Ⅱ：支付的时候有一个折扣，因为折扣相对简单，把折扣直接写在了支付微服务里 。

Ⅰ、发展：随着系统不断维护，用户提出各种算法关于折扣，折扣越来越复杂，但是折扣是支付所维护的。
Ⅱ、问题：折扣变化不应该是支付引起变化的原因。
Ⅲ、改造：把折扣单独拎出来，做一个服务，变更就在折扣服务去变更。