IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle)
定义
就一个类而言,应该仅有一个引起它变化的原因。
定义解读
这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。
优点
- 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多;
- 类的可读性增强,阅读起来轻松;
- 可维护性强,一个易读、简单的类自然也容易维护;
- 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
问题提出
假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。
解决方案
遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。
说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
比如:类C只负责一个职责P,这样设计是符合单一职责原则的。后来由于某种原因,也许是需求变更了,也许是客户提出了新的功能,需要将职责P细分为粒度更细的职责P1,P2,这时如果要使程序遵循单一职责原则,需要将类C也分解为两个类C1和C2,分别负责P1、P2两个职责。但是在程序已经写好的情况下,这样做有时候需要花费更多的工作量。在项目工期紧张的情况下,我们通常会简单的修改类C,用它来负责两个职责,虽然这样做有悖于单一职责原则。(这样做的风险在于职责扩散的不确定性,因为在未来可能会扩散出P1,P2,P3,P4……Pn。所以记住,在职责扩散到我们无法控制的程度之前,立刻对代码进行重构。)
示例
说一个和我们密切相关的场景:员工的工资计算。刚开始的时候,我们会新建一个员工类,在员工类里面有一个计算工资的方法,代码如下所示:
.h文件:
- @interface Employee : NSObject
- // 计算工资
- - (void)calculateSalary:(NSString *)name;
- @end
.m文件:
- #import "Employee.h"
- @implementation Employee
- - (void)calculateSalary:(NSString *)name
- {
- NSLog(@"%@的工资是100",name);
- }
- @end
调用代码:
- Employee *employee = [[Employee alloc] init];
- [employee calculateSalary:@"张三"];
- [employee calculateSalary:@"李四"];
- [employee release];
输出结果如下:
张三的工资是100
李四的工资是100
产品上线后,问题出来了,因为员工的岗位不同,工资的计算是不一样的。修改时如果遵循单一职责原则,需要将Employee类细分为总监类Director、经理类Manager、普通员工类Staff,这三个类的实现代码和Employee类一样,只是方法calculateSalary有所不同,这里就不贴出来了,调用代码如下:
- Director *director = [[Director alloc] init];
- Manager *manager = [[Manager alloc] init];
- Staff *staff = [[Staff alloc] init];
- [director calculateSalary:@"张三"];
- [manager calculateSalary:@"李四"];
- [staff calculateSalary:@"王五"];
- [director release];
- [manager release];
- [staff release];
输出结果如下:
张三总监的工资是10000
李四经理的工资是1000
王五员工的工资是100
上面的修改方式是在遵循单一职责原则下进行的,从修改中,我们可以看到,这样修改的工作量相对较大,需要新增不同的岗位类,还需要修改调用代码。实际项目开发中,我们可能会采取如下两种方式:
【方式一】:直接修改Employee类里面的calculateSalary方法,在这里,我们需要对calculateSalary方法增加一个参数,以标识员工的岗位。
修改后的calculateSalary方法如下所示:
- // 计算工资,增加员工岗位的标识(Director:总监;Manager:经理;Staff:普通员工)
- - (void)calculateSalary:(NSString *)name flag:(NSString *)flag
- {
- if ([flag isEqualToString:@"Director"])
- {
- NSLog(@"%@总监的工资是10000",name);
- }
- else if ([flag isEqualToString:@"Manager"])
- {
- NSLog(@"%@经理的工资是1000",name);
- }
- else if ([flag isEqualToString:@"Staff"])
- {
- NSLog(@"%@员工的工资是100",name);
- }
- }
调用代码如下:
- Employee *employee = [[Employee alloc] init];
- [employee calculateSalary:@"张三" flag:@"Director"];
- [employee calculateSalary:@"李四" flag:@"Manager"];
- [employee calculateSalary:@"王五" flag:@"Staff"];
- [employee release];
输出结果如下:
张三总监的工资是10000
李四经理的工资是1000
王五员工的工资是100
从上面可以看到,这种修改方式相对要简单的多,是直接在代码级别上违背了单一职责原则,虽然修改起来最简单,但隐患却也是最大的。假设有一天需要将总监分为财务总监和研发总监,则又需要修改Employee类的calculateSalary方法,而对原有代码的修改会对已有功能带来风险(可能会存在遗漏或者疏忽)。
【方式二】:在Employee类中新增不同岗位的工资计算方法,.h文件中新加的方法定义如下所示:
- // 总监工资计算
- - (void)directorCalculateSalary:(NSString *)name;
- // 经理工资计算
- - (void)managerCalculateSalary:(NSString *)name;
- // 普通员工工资计算
- - (void)staffCalculateSalary:(NSString *)name;
调用代码如下:
- Employee *employee = [[Employee alloc] init];
- [employee directorCalculateSalary:@"张三"];
- [employee managerCalculateSalary:@"李四"];
- [employee staffCalculateSalary:@"王五"];
- [employee release];
输出结果如下:
张三总监的工资是10000
李四经理的工资是1000
王五员工的工资是100
可以看到,方式二没有改动原来的方法,而是在类中新加了三个方法,这样虽然也违背了单一职责原则,但在方法级别上却是符合单一职责原则,因为它并没有改变原来方法的代码。
示例总结
上面三种方式各有优缺点,那么在实际编程中,该采用哪一种呢?这个问题没有标准答案,需要根据实际情况来确定。
IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle)的更多相关文章
- IOS设计模式的六大设计原则之开放-关闭原则(OCP,Open-Close Principle)
定义 一个软件实体(如类.模块.函数)应当对扩展开放,对修改关闭. 定义解读 在项目开发的时候,都不能指望需求是确定不变化的,大部分情况下,需求是变化的.那么如何应对需求变化的情况?这就是开放-关闭原 ...
- 面向对象的六大原则之 单一职责原则——SRP
SRP = Single Responsibility Principle 定义:就一个类而言,应该只有一个能引起他变化的原因.通俗的说,即一个类只负责一项职责. 作用: 1.减少了类之间的耦 ...
- 开放-封闭原则(OCP)开-闭原则 和 依赖倒转原则,单一职责原则
单一职责原则 1.单一职责原则(SRP),就一个类而言,应该仅有一个引起它变化的原因 2.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或抑制这个类完成其他职责的能力. ...
- IOS设计模式的六大设计原则之接口隔离原则(ISP,Interface Segregation Principle)
定义 客户端不应该依赖它不需要的接口: 一个类对另一个类的依赖应该建立在最小的接口上. 定义解读 定义包含三层含义: 一个类对另一个类的依赖应该建立在最小的接口上: 一个接口代表一个角色,不应该将不同 ...
- 《javascript设计模式与开发实践》--- (单一职责原则)
看的这本书叫<JavaScript设计模式与开发实践> 先规划一下看书的顺序,基础知识我已经大概的浏览了一遍了,没有留下笔记,以后有时间还会补上.本来打算顺着看的.但是我感觉我很难短时间内 ...
- 设计模式笔记:单一职责原则(SRP, Single Responsibility Principle)
1. 单一职责原则核心思想 一个类应该有且只有一个变化的原因. 2. 为什么引入单一职责原则 单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心. 在SRP中,把职责定义为变化的原因 ...
- [Python设计模式] 第3~5章 单一职责原则/开放-封闭原则/依赖倒转原则
github地址:https://github.com/cheesezh/python_design_patterns 单一职责原则 就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责 ...
- 最简单直接地理解Java软件设计原则之单一职责原则
理论性知识 定义 单一职责原则, Single responsibility principle (SRP): 一个类,接口,方法只负责一项职责: 不要存在多余一个导致类变更的原因: 优点 降低类的复 ...
- 面向对象五大原则_1.单一职责原则&2.里氏替换原则
单一职责原则:Single Responsibility Principle (SRP) 一个类.仅仅有一个引起它变化的原因.应该仅仅有一个职责.每个职责都是变化的一个轴线.假设一个类有一个以上的职责 ...
随机推荐
- 键盘事件OnKeyListener
1.效果图:就是在文本框中输入A,则显示A,输入B,则显示B.... (1)activity_main.xml <?xml version="1.0" encoding=&q ...
- 在GIT中修改提交记录
在SVN中,提交记录是无法修改的.比如说,当我们提交了某次修改后,发现该次提交中有错误时,只能将将补丁再次提交一遍.这样,就存在两次提交记录,没有保证提交的原子性. 在GIT中,由于提交是在本地进行的 ...
- Mysql 按条件排序查询一条记录 top 1 对应Mysql的LIMIT 关键字
项目中需要每次查询一个表中的最新的一条记录,表结构里面有日期字段.只需要显示一条记录. Mysql帮助文档里面的解释 3.6.2. 拥有某个列的最大值的行 任务:找出最贵物品的编号.销售商和价格. 这 ...
- C#中Math的使用总结
1.向上进位取整.Math.Ceiling 例如: Math.Ceiling(32.6)=33; Math.Ceiling(32.0)=32; 2.向下舍位取整.Math.Floor 例如: Math ...
- html5:localStorage储存
实例:刷新值会增长,关掉浏览器,再打开,值会在原基础上增长 if(localStorage.pagecount){ localStorage.pagecount=Number(localStorage ...
- canvas如何兼容IE8
大家都知道canvas是个非常好玩的东西,但是IE9以下的浏览器不支持,有时候业务需求必须用到canvas,且又要求兼容IE8浏览器,那怎么办呢? 1.添加对html5的支持:<!--[if I ...
- python3读取html文件
# htmlf=open('E:\\test2.html','r',encoding="utf-8") # htmlcont=htmlf.read() # print(type(h ...
- jquery修改ajax的header的字段origin方法,均被浏览器拒绝
一.方法一 $.ajax({ headers: { Origin: "http://targetIP" } }); 二.方法二 $.ajax({ beforeSend: funct ...
- 关于 Delphi 中流的使用(2) 用 TFileStream(文件流) 读写
TStream 是一个抽象的基类, 不能直接生成对象. 在具体的应用中, 主要使用它的子孙类:TFileStream: 文件流TStringStream: 字符串流TMemoryStream: 内存流 ...
- java获取src下包的文件的路径
String params = getClass().getClassLoader().getResource("system-config.properties").getPat ...