30-2 之软件架构设计原则 1 - SRP 单一职责原则

软件架构设计原则 1 - SRP 单一职责原则

在软件设计有个『 SOLID 原则』的几个原则，它是由 5 个原则所组成，而这 5 个原则所想要达的的事情为以下两点 :

低耦合
高内聚

接下来这篇文章我们将要谈谈第一个原则 SRP 单一职责原则

SRP ( Single-Responsibility Principle ) 是什麽呢 ?

SRP 单一职责原则，最一开始是由一位叫 Robert Cecil Martin 在他的《敏捷软件开发，原则，模式和实践》一书中所提到的『物件导向设计原则』

一个『类别』只对一个『原因』引起变化 ( A class should have only one reason to change )

然後这位作者在之後出版的一本书《 Clean Architecture 》又将定义修改成如下 :

一个『类别』只有一个『角色』引起『变化』

那这一个『角色』指的是什麽呢 ? 而『变化』又是什麽呢 ? 我这里自已的想法为 :

『角色』代表这个类别的使用者 ( 想成实体化後执行方法的地方 )，而『变化』代表『因为这角色某个需求，而需要去修改程序码。

上面这句话，我们接下来用下面的范例，来简单说明。

范例 - 订单计算直播人数

假设我们有个类别，计算直播的观看数，就是简单的去资料库拿资料 ( 这只是范例，我知道有些情况不适合去 DB 拿这个数字 )。

// Bad SRP
class LiveViewCountCalculator{
    constructor(){
        // 假设每个笔单只有一种类型的产品
    }

    calcFee(){
        let viewCount = 0
        viewCount = await _getViewCountFromDB()
        return viewCount
    }
}

然後目前会使用这个方法的两种角色『前台给观众看』、『後台给直播主、工作人陨看』，在需求没有变动的情况下没什麽问题。

但如果这时前台给观众看的决定灌水怎麽办呢 ?

如果这时改了，『就同时会影响到後台给直播主看的实际数字』，所以如果修改成如下会比较好点，根据『角色』来拆，这样一个角色的改变，就不会影响到另一个角色。

// Good SRP

class AdminLiveViewCountCalculator{
    calcFee(){
        let viewCount = 0
        viewCount = await _getViewCountFromDB()
        return viewCount
    }
}

class GeneralLiveViewCountCalculator{
    calcFee(){
        let viewCount = 0
        viewCount = await _getViewCountFromDB()
        return viewCount * 2
    }
}

那是不是一切都要『根据角色』切分呢 ?

事实上是不一定，在《敏捷软件开发，原则，模式和实践》里有提到 :

If the application changes in ways that affect the signature of the connection functions, then the design will smell of Rigidity... In that case the two responsibilities should be separated. If, on the other hand, the application is not changing in ways that cause the two responsibilities to change at different times, then there is no need to separate them.

这个是我自已的理解的想法，如果每一次的改动对不同的角色事实上都是连动的，那就没必要拆开，而如果是一个角色动，会影响到另一个角色使用，则拆。