聊聊设计模式原则(一) -- 单一职责原则

设计模式

Posted by CatchZeng on February 19, 2017

目录

单一职责原则(SRP:Single responsibility principle)

定义

一个类应该只有一个发生变化的原因,即一个类只负责一项职责。 如果一个类有多个职责,这些职责就耦合在了一起。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起会影响复用性。 此原则的核心是解耦和增强内聚性。

由来

类A负责两个职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类A时,有可能会导致原本运行正常的职责P2功能发生故障。

解决方案

遵循SRP。分别建立两个类A1、A2,使A1完成职责P1,A2完成职责P2。这样,当修改类A1时,不会影响到职责A2;同理,当修改A2时,也不会影响到职责P1。

优点

降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多。 提高类的可读性,提高系统的可维护性。 变更引起的风险降低,变更是必然的,如果SRP遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。

e.g.

iOS开发中,SRP最好的反例的应该就是 Massive View Controller。比如随便写一个简单的应用程序,一般都会生成一个ViewController类,于是我们将各种各样的代码,算法、网络请求、数据库访问等等都放在这个类里面,这就意味着,无论任何需求变化,都要来修改ViewController这个类,这其实是很糟糕的,维护麻烦、复用不可能、缺乏灵活性等。关于这点网上也有很多解决方法:8 种模式帮你告别 Massive View Controller,但无论什么方法,都是在提倡优化职责划分,也就是SRP的思想。

曾几何时我们很自然地将Model传给Cell,然后让Cell解析Model去渲染视图,并且感觉没有什么不妥,美其曰“Cell的封装”。代码如下:

TestCell *cell = [tableView dequeueReusableCellWithIdentifier:@"TestCell"];
if (!cell) {
        cell = (TestCell *)[[[NSBundle mainBundle] loadNibNamed:@"TestCell" owner:self options:nil] lastObject];
}
TestModel *model = self.dataList[indexPath.row];
[cell configWithModel:model];

殊不知这已经违背了SRP,Cell的职责是描述与渲染自身,解析Model这个职责不属于Cell,并且在Cell中引入Model会增加不必要的依赖,Cell需要根据Model的改变而做出相应的修改,不利于Cell的复用。做过Android开发的同学知道,其实如何让Model的数据呈现在Cell上是Adapter需要做的事情。

一些看法

用一个场景来描绘下。 用一个类描述程序员写代码

@implementation Programmer
-(Void) program:(NSString* name){
    NSLog(@"%@写OC代码",name);
}
@end

//Client
Programmer* programmer = [[Programmer alloc]init];
[programmer program:@"iOS工程师"];

//Result
iOS工程师写OC代码”

殊不知,iOS只是代码界的一部分

[programmer program:@"前端工程师"];

//Result
“前端工程师写OC代码”

发现不对劲了,这个时候想到了SRP,要不这样改改

@implementation IOSProgrammer
-(Void) program:(NSString* name){
    NSLog(@"%@写OC代码",name);
}
@end

@implementation WebProgrammer
-(Void) program:(NSString* name){
    NSLog(@"%@写JS代码",name);
}
@end

//Client
IOSProgrammer* iOSprogrammer = [[IOSProgrammer alloc]init];
[iOSprogrammer program:@"iOS工程师"];
WebProgrammer* webProgrammer = [[WebProgrammer alloc]init];
[webProgrammer program:@"前端工程师"];

//Result
iOS工程师写OC代码”
“前端工程师写JS代码”

我们会发现如果这样修改花销是很大的,除了将原来的类分解之外,还需要修改客户端。而直接修改类Programmer来达成目的虽然违背了SRP但花销却小的多,代码如下:

@implementation Programmer
-(Void) program:(NSString* name){
    if([name isEqualToString:@"iOS工程师"]){
        NSLog(@"%@写OC代码",name);
    }else  if([name isEqualToString:@"前端工程师"]){
        NSLog(@"%@写JS代码",name);
    }
}
@end

可以看到,这种修改方式要简单的多。但是却存在着隐患:有一天需要后台程序员写PHP,则又需要修改Programmer类的program方法,而对原有代码的修改会对调用iOS工程师、前端工程师带来风险。这种修改方式直接在代码级别上违背了SRP,虽然修改起来最简单,但隐患却是最大。 那么还有别的方式吗?答案是肯定的,代码如下:

@implementation Programmer
-(Void) program:(NSString* name){
    NSLog(@"%@写OC代码",name);
}

-(Void) program2:(NSString* name){
    NSLog(@"%@写JS代码",name);
}
@end

//Client
Programmer* programmer = [[Programmer alloc]init];
[programmer program:@"iOS工程师"];
Programmer* programmer2 = [[Programmer alloc]init];
[programmer2 program2:@"前端工程师"];

//Result
iOS工程师写OC代码”
“前端工程师写JS代码”

这种在类中新加一个方法的修改方式,虽然也违背了SRP,但在方法级别上却是符合SRP的,因为它并没有动原来方法的代码。 这三种方式各有优缺点,在开发中,需要根据实际情况来确定。需要注意的是:只有逻辑足够简单,才可以在代码级别上违反SRP;只有类中方法数量足够少,才可以在方法级别上违反SRP;

很多人对SRP不屑一顾,因为它太简单了。但即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。其原因是因为有职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。需要注意的是:在职责扩散到我们无法控制的程度之前,要立刻对代码进行重构。