IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle)

定义

  就一个类而言,应该仅有一个引起它变化的原因。

定义解读

  这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。

优点

  • 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多;
  • 类的可读性增强,阅读起来轻松;
  • 可维护性强,一个易读、简单的类自然也容易维护;
  • 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。

问题提出

  假设有一个类C,它负责两个不同的职责:职责P1P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。

解决方案

  遵循单一职责原则。分别建立两个类C1C2,使C1完成职责P1C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。

  说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1P2

  比如:类C只负责一个职责P,这样设计是符合单一职责原则的。后来由于某种原因,也许是需求变更了,也许是客户提出了新的功能,需要将职责P细分为粒度更细的职责P1P2,这时如果要使程序遵循单一职责原则,需要将类C也分解为两个类C1C2,分别负责P1P2两个职责。但是在程序已经写好的情况下,这样做有时候需要花费更多的工作量。在项目工期紧张的情况下,我们通常会简单的修改类C,用它来负责两个职责,虽然这样做有悖于单一职责原则。(这样做的风险在于职责扩散的不确定性,因为在未来可能会扩散出P1P2P3P4……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];
2         [employee directorCalculateSalary:@"张三"];
3         [employee managerCalculateSalary:@"李四"];
4         [employee staffCalculateSalary:@"王五"];
5         [employee release];

输出结果如下:

张三总监的工资是10000

李四经理的工资是1000

王五员工的工资是100

  可以看到,方式二没有改动原来的方法,而是在类中新加了三个方法,这样虽然也违背了单一职责原则,但在方法级别上却是符合单一职责原则,因为它并没有改变原来方法的代码。

示例总结

上面三种方式各有优缺点,那么在实际编程中,该采用哪一种呢?这个问题没有标准答案,需要根据实际情况来确定。

 

源码下载   返回目录

posted @ 2013-11-28 14:59  Gof Lee  阅读(2278)  评论(2编辑  收藏  举报