首页 > 代码库 > 设计原则之单一职责原则
设计原则之单一职责原则
定义:一个类只负责一项职责,应该只有一个能引起它变化的原因。
问题:类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中添加一个新的方法用于介绍鱼的栖息地和食物,这样不会影响到
之前的功能了,如下:
运行后的效果是:
可以看到,这种修改方式没有去改动原来的方法,所以不会影响到原有功能的使用,在方法级别上是符合单一职责原则的。
原则:如果一个类承担的职责越多,那么它被复用的可能性就越小,并且一个类承担的职责过多的话,这些职责就会耦合在一起,
当其中一个职责发生改变时,就可能会影响到其他职责的运作,这样的话势必会影响到后期功能的优化或扩展。
将这些职责进行适当地分离,将不同的职责封装到不同的类中,注意的是对于那些总是同时发生改变的多个职责,可将
它们封装在同一类中。
优点:高内聚,低耦合。可降低类的复杂度,提高类的可读性,提高系统的可维护性,在一定程度上降低变更引起的风险。
设计原则之单一职责原则
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。