目录
单一职责原则（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。需要注意的是：在职责扩散到我们无法控制的程度之前，要立刻对代码进行重构。
