首页 > 代码库 > 设计原则之单一职责原则

设计原则之单一职责原则

定义:一个类只负责一项职责,应该只有一个能引起它变化的原因。

问题:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常
的职责P2功能发生故障。

解决:分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;
同理,当修改T2时,也不会使职责P1发生故障风险。

举个栗子:介绍几种动物的栖息地和食物,这里边有两项职责:栖息地和食物。

用一个类Recommend介绍牛生活在陆地上,吃的是青草;羊生活在陆地上,吃的是青草。

技术分享

技术分享

运行后的结果是:

技术分享

以上,类Recommend负责两个不同的职责:职责P1(动物),职责P2(栖息地),当职责P1发生改变,比如增加一个动物猪的时候,猪吃的不是青草,
那么我们就需要修改类Recommend,修改的方式有两种:

一是将类Recommend分解成类Recommend01和类Recommend02,如下:

技术分享

技术分享

然后在SRPFragment中分别调用:

技术分享

运行后的结果是:

技术分享

可以看出,将原来的类Recommend进行分解的做法,不仅修改的花销很大,还需要修改SRPFragment中的代码,所以不推荐。
我们能不能直接修改类Recommend呢?
二是在类Recommend的rede方法中加个判断,来区分吃青草的牛羊和吃五谷杂粮的猪:

技术分享

技术分享

运行后的结果是同上。
如此修改要简单得多,但当我们再加一种动物鱼的时候,又要去修改类Recommend中的rede方法,假设rede方法很复杂,那么就会对
原有的方法带来风险。
所以我们就要用到单一职责原则来解决这个问题,在类Recommend中添加一个新的方法用于介绍鱼的栖息地和食物,这样不会影响到
之前的功能了,如下:

技术分享

技术分享

运行后的效果是:

技术分享

可以看到,这种修改方式没有去改动原来的方法,所以不会影响到原有功能的使用,在方法级别上是符合单一职责原则的。
原则:如果一个类承担的职责越多,那么它被复用的可能性就越小,并且一个类承担的职责过多的话,这些职责就会耦合在一起,
当其中一个职责发生改变时,就可能会影响到其他职责的运作,这样的话势必会影响到后期功能的优化或扩展。
将这些职责进行适当地分离,将不同的职责封装到不同的类中,注意的是对于那些总是同时发生改变的多个职责,可将
它们封装在同一类中。

优点:高内聚,低耦合。可降低类的复杂度,提高类的可读性,提高系统的可维护性,在一定程度上降低变更引起的风险。

设计原则之单一职责原则