六大设计原则之 单一职责原则
关于单一职责原则,我想大家都听过不少,今天来看看这个原则具体是什么,有哪些好处使我们需要选择遵守它呢?
一、定义
一个类只能因为一个原因而修改。
怎么理解呢?简单来说,一个类只能实现一项功能,或者换句话说,一个类只有一个职责,只有当这个职责发生变化,它才会被修改,
说白了就是一个类质感一个类该干的事。
二、好处
- 类的复杂性降低
- 可读性提高
- 可维护性提高
- 变革引起的风险降低
三、难点
难点就在于,有的时候这个职责的划分是没有标准答案的,它会根据你项目的大小,时间等一系列的参数而改变,并且一个类并不是说越小越好,要根据实际情况来定。
四、代码示例
下面我们看一个代码,实现一个“人”类:
代码不难,这里有3个属性,还有3个方法,OK?
这段代码有什么问题呢?他不符合单一职责原则(并不绝对),为什么这么说呢?
因为他将人的属性和方法封装在一起了,这样如果人的属性增加了,例如增加一项 “肤色"那么很明显这个类需要改变;那我增加一个方法呢,人需要: ”工作“那么类还需要改变,这是两个职责,但他都引起类的变化,这是不好的(不能说是不对的)。那我怎么办?看下面的代码:
一个人 属性类
一个人 方法接口
一个真正的人 张三
最后是场景类
运行结果:
姓名:张三
我是张三,我爱吃饭
我是张三,我需要解手
我是张三,我爱睡觉
好,上面的代码,我增加了一个人活动接口,具体的人继承 人类同时实现人类活动的接口。这样你要增加属性,我就该Person类,如果改变方法,我就该PersonDo接口就好了。
当然说到这里,可能就有人会说,P啊,我就觉得人就应该有属性和方法一起,没有属性的人不是人,不会方法的人没法活,我就要放在一起
咋啦?没问题,完全可以,应为对于每个人来说,职责是不一样的,只要不是太大的问题,具体设计由你来定,当然或者说由你的BOSS定。
特别提示:如果有个你看不顺眼的家伙总是在你身边唧唧歪歪:我又写了个牛X程序,那么你就说”你那玩意,符合单一职责原则吗?“大部分情况下,他就傻了..................