单一职责原则
个人博客原文: 单一职责原则
设计模式六大原则之一:单一职责原则
简介
姓名 :单一职责原则 英文名 :Single Responsibility Principle 座右铭 :There should never be more than one reason for a class to change. 应当有且仅有一个原因引起类的变更。。。意思就是不管干啥,我都只干一件事,你叫我去买菜,我就只买菜,叫我顺便去倒垃圾就不干了,就这么拽 脾气 :一个字“拽”,两个字“特拽“ 伴侣 :老子职责单一,哪来的伴侣? 个人介绍 :在这个人兼多责的社会里,我显得那么的特立独行,殊不知,现在社会上发生的很多事情都是因为没有处理好职责导致的,比如,经常有些父母带着小孩,一边玩手机,导致小孩弄丢、发生事故等等
单一职责应用范围
单一职责原则适用的范围有接口、方法、类。按大家的说法,接口和方法必须保证单一职责,类就不必保证,只要符合业务就行。
方法
设想一下这个场景:假设我们要做一个用户修改名字以及修改密码的功能,可以有多种实现方案,比如下面列举 2 种实现方式 代码:SrpOfMethod.java
第一种实现方式
/** * 错误的示范 */ enum OprType { /** * 更新密码 */ UPDATE_PASSWORD, /** * 更新名字 */ UPDATE_NAME; } interface UserOpr { boolean updateUserInfo(User user, OprType oprType); } class UserOprImpl implements UserOpr { @Override public boolean updateUserInfo(User user, OprType oprType) { if (oprType == OprType.UPDATE_NAME) { // update name } else if (oprType == OprType.UPDATE_PASSWORD) { // update password } return true; } }
第二种实现方式
/** * 正确的示范 */ interface UserOpr2 { boolean updatePassword(User user, String password); boolean updateUserInfo(User user); } class UserOprImpl2 implements UserOpr2 { @Override public boolean updatePassword(User user, String password) { user.setPassword(password); // update password return true; } @Override public boolean updateUserInfo(User user) { // update user info return true; } }
2 种实现有什么区别呢? 第一种实现通过 OprType 类型的不同来做不同的事情,把修改密码和修改名字耦合在一起,容易引起问题,只要稍不注意,传错枚举值就悲剧了,在代码中也没法很直接看到是做什么操作,也就是这个方法的职责不明确。而第二种实现,把修改密码和修改名字分离开来,也就是把修改密码和修改名字都当做独自的职责处理,这样子就很清晰明了,你调用哪个方法,就很明确的知道这个方法是实现什么逻辑。结论是啥呢?用第二种方式实习才符合单一职责原则。现实中看到很多像第一种实现的代码,而且是枚举有十来个的情况,看代码真费劲。
接口
设想一下这个场景,假设我们让小明去倒垃圾,小红去买菜,小红回来后再叫小红去洗碗。下面也举 2 个实现的例子。 代码:SrpOfInterface.java
第一种实现方式
/** * 错误的示范 */ interface Housework { void shopping(); void pourGarbage(); } class XiaoMing implements Housework { @Override public void shopping() { // 不购物 } @Override public void pourGarbage() { System.out.println("pourGarbage ..."); } } class XiaoHong implements Housework { @Override public void shopping() { System.out.println("shopping ..."); } @Override public void pourGarbage() { // 从不倒垃圾 } }
中途回来小红去洗碗,要怎么实现?按这个写法,就在 Housework 接口添加 washingUp() 方法,然后小明和小红依次都实现洗碗这个方法,只是小明不做具体实现代码,这样子是不是觉得很别扭,不符合单一职责原则的,修改一个地方,不影响其他不需要改变的地方,只对需要用到的地方做修改。小明本来就不用洗碗,却要去实现洗碗这个方法。
第二种实现方式
/** * 正确的示范 */ interface Shopping { void doShopping(); } interface PourGarbage { void doPourGarbage(); } interface WashingUp { void doWashingUp(); } class XiaoMing2 implements PourGarbage { @Override public void doPourGarbage() { System.out.println("pourGarbage ..."); } } class XiaoHong2 implements Shopping, WashingUp { @Override public void doShopping() { System.out.println("shopping ..."); } @Override public void doWashingUp() { System.out.println("washing up ..."); } }
可以看到,这种实现把不同的家务都当做不同的职责,分离开来,这种实现可以按需实现做家务的类型,小明只需要去倒垃圾,就实现 PourGarbage 接口,小红去购物和洗碗,就实现 Shopping 和 WashingUp 接口,完全不会影响到对方,这才是完美的根据单一职责原则编写出来的代码。
类
类这个看了一些资料都说没法硬性要求一定按单一职责原则分,或者说类的职责可大可小,没有很明确的像上面接口那样按照单一职责原则分就很清晰也很有道理。 设想一下这个场景:我们要实现一个用户注册、登录、注销操作,可以像如下 2 种实现方式 代码:SrpOfClass.java
第一种实现方式
从用户的角度考虑,这些操作都是用户的行为,可以放在一个统一的类 UserBiz
class UserBiz { public boolean register(User user){ // 注册操作 return true; } public boolean login(User user) { // 登录操作 return true; } public boolean logout(User user) { // 注销操作 return true; } }
第二种实现方式
有人又说,不是说单一职责么?从业务操作考虑,需要把注册、登录、注销分开
class UserRegisterBiz { public boolean register(User user){ // 注册操作 return true; } } class UserLoginBiz { public boolean login(User user) { // 登录操作 return true; } } class UserLogoutBiz { public boolean logout(User user) { // 注销操作 return true; } }
感觉像是在抬杠,其实这个没有好坏之分,根据具体业务具体分析,你说你的登录、注册、注销操作代码很多,需要分开,那就分开,无可厚非。
好处
- 类的复杂性降低,实现什么职责都有清晰明确的定义
- 可读性提高,复杂性降低,那当然可读性提高了
- 可维护性提高,可读性提高,那当然更容易维护了
- 变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助 (来自《设计模式之禅》)
总结
这个单一职责原则,目的就是提高代码的可维护性、可读性、扩展性,如果为了单一职责而破坏了这 3 个特性,可能会得不偿失。
参考资料:《大话设计模式》、《Java设计模式》、《设计模式之禅》、《研磨设计模式》、《Head First 设计模式》
希望文章对您有所帮助,设计模式系列会持续更新,感兴趣的同学可以关注公众号,第一时间获取文章推送阅读,也可以一起交流,交个朋友。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Flink中的多source+event watermark测试
这次需要做一个监控项目,全网日志的指标计算,上线的话,计算量应该是百亿/天 单个source对应的sql如下 最原始的sql select pro,throwable,level,ip,`count`,id,`time`,firstl,lastl from ( select pro,throwable,level,ip, count(*) as `count`, lastStrInGroupSkipNull(CONCAT_WS('_',KAFKA_TOPIC,CAST(KAFKA_PARTITION AS VARCHAR),CAST(KAFKA_OFFSET as VARCHAR))) as id, firstLong(l) as firstl, lastLong(l) as lastl, TUMBLE_END(SPT, INTERVAL '3' SECOND) as `time` from input.`ymm-appmetric-dev-self1` where pro IS NOT NULL and throwable IS ...
- 下一篇
Python进阶:自定义对象实现切片功能
2018-12-31 更新声明:切片系列文章本是分三篇写成,现已合并成一篇。合并后,修正了一些严重的错误(如自定义序列切片的部分),还对行文结构与章节衔接做了大量改动。原系列的单篇就不删除了,毕竟也是有单独成篇的作用。特此声明,请阅读改进版—— Python进阶:全面解读高级特性之切片!https://mp.weixin.qq.com/s/IRAjR-KHZBPEEkdiofseGQ 切片是 Python 中最迷人最强大最 Amazing 的语言特性(几乎没有之一),在《Python进阶:切片的误区与高级用法》中,我介绍了切片的基础用法、高级用法以及一些使用误区。这些内容都是基于原生的序列类型(如字符串、列表、元组......),那么,我们是否可以定义自己的序列类型并让它支持切片语法呢?更进一步,我们是否可以自定义其它对象(如字典)并让它支持切片呢? 1、魔术方法:__getitem__() 想要使自定义对象支持切片语法并不难,只需要在定义类的时候给它实现魔术方法 __getitem__() 即可。所以,这里就先介绍一下这个方法。 语法: object.__getitem__(self...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- 2048小游戏-低调大师作品
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池