没有合适的资源?快使用搜索试试~ 我知道了~
1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义 就一个类而言,应该仅有一个引起它变化的原因。 定义解读 这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出 假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案 遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。 说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
资源推荐
资源详情
资源评论











第部分 设计模式的六设计原则
1、 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件:
1 @interface Employee : NSObject
2
3 // 计算资
4 - (void)calculateSalary:(NSString *)name;

5
6 @end
.m件:
1 #import "Employee.h"
2
3 @implementation Employee
4
5 - (void)calculateSalary:(NSString *)name
6 {
7 NSLog(@"%@的资是100",name);
8 }
9
10
11 @end
调代码:
1 Employee *employee = [[Employee alloc] init];
2 [employee calculateSalary:@"张三"];
3 [employee calculateSalary:@"李四"];
4 [employee release];
输出结果如下:
张三的资是100
李四的资是100
产品上线后,问题出来了,因为员的岗位不同,资的计算是不样的。修改时如果遵
循单职责原则,需要将Employee类细分为总监类Director、经理类Manager、普通员
类Staff,这三个类的实现代码和Employee类样,只是法calculateSalary有所不
同,这就不贴出来了,调代码如下:
1 Director *director = [[Director alloc] init];
2 Manager *manager = [[Manager alloc] init];
3 Staff *staff = [[Staff alloc] init];
4
5 [director calculateSalary:@"张三"];
6 [manager calculateSalary:@"李四"];
7 [staff calculateSalary:@"五"];
8
9 [director release];
10 [manager release];
11 [staff release];
输出结果如下:
张三总监的资是10000
李四经理的资是1000
五员的资是100
上的修改式是在遵循单职责原则下进的,从修改中,我们可以看到,这样修改的
作量相对较,需要新增不同的岗位类,还需要修改调代码。实际项开发中,我们可能
会采取如下两种式:
【式】:直接修改Employee类的calculateSalary法,在这,我们需要

对calculateSalary法增加个参数,以标识员的岗位。
修改后的calculateSalary法如下所:
1 // 计算资,增加员岗位的标识(Director:总监;Manager:经理;Staff:普通员
)
2 - (void)calculateSalary:(NSString *)name flag:(NSString *)flag
3 {
4 if ([flag isEqualToString:@"Director"])
5 {
6 NSLog(@"%@总监的资是10000",name);
7 }
8 else if ([flag isEqualToString:@"Manager"])
9 {
10 NSLog(@"%@经理的资是1000",name);
11 }
12 else if ([flag isEqualToString:@"Staff"])
13 {
14 NSLog(@"%@员的资是100",name);
15 }
16 }
调代码如下:
1 Employee *employee = [[Employee alloc] init];
2 [employee calculateSalary:@"张三" flag:@"Director"];
3 [employee calculateSalary:@"李四" flag:@"Manager"];
4 [employee calculateSalary:@"五" flag:@"Staff"];
5 [employee release];
输出结果如下:
张三总监的资是10000
李四经理的资是1000
五员的资是100
从上可以看到,这种修改式相对要简单的多,是直接在代码级别上违背了单职责原
则,虽然修改起来最简单,但隐患却也是最的。假设有天需要将总监分为财务总监和研发
总监,则需要修改Employee类的calculateSalary法,对原有代码的修改会对已有
功能带来险(可能会存在遗漏或者疏忽)。
【式】:在Employee类中新增不同岗位的资计算法,.h件中新加的法定
义如下所:
1 // 总监资计算
2 - (void)directorCalculateSalary:(NSString *)name;
3
4 // 经理资计算
5 - (void)managerCalculateSalary:(NSString *)name;
6
7 // 普通员资计算
8 - (void)staffCalculateSalary:(NSString *)name;
调代码如下:
1 Employee *employee = [[Employee alloc] init];
剩余15页未读,继续阅读
资源评论


w1243
- 粉丝: 0
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助


最新资源
- PLC皮带运输监控系统设计方案.doc
- 网络传播视阈下的地区形象改善策略研究.docx
- 初学者必看!PLC与常见设备连接方式.doc
- plc原理设计的自动售货机.doc
- 汽车零部件行业MRP信息化平台技术.ppt
- 基于PLC实现的彩灯广告牌方案设计书.doc
- 区块链基础:非技术性25步指南
- 北京市通信公司综合业务楼工程大体积砼施工组织设计方案.doc
- 大数据时代互联网广告的营销模式分析.docx
- 浙江省传统村落调研资料数据库的建立与应用研究.docx
- 【精品ppt】互联网+电子商务创新创业融资竞赛-(1).pptx
- 基于PLC交通灯控制系统大学本科方案设计书[1]177.doc
- 通信部队信息化建设存在的问题及解决措施.docx
- 大数据背景下企业人力资源绩效管理创新探讨.docx
- 适用于预测性维护与健康管理的故障诊断及剩余使用寿命预测大型语言模型
- 软件工程期末考试题3.doc
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈



安全验证
文档复制为VIP权益,开通VIP直接复制
