定义
就一个类而言，应该仅有一个引起它变化的原因。
定义解读
这是六大原则中最简单的一种，通俗点说，就是不存在多个原因使得一个类发生变化，也就是一个类只负责一种职责的工作。
优点
- 类的复杂度降低，一个类只负责一个功能，其逻辑要比负责多项功能简单的多；
- 类的可读性增强，阅读起来轻松；
- 可维护性强，一个易读、简单的类自然也容易维护；
- 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
问题提出
假设有一个类 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:@"李四"];
输出结果
张三的工资是：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:@"王五"];
输出结果
张三总监的工资是：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"];
输出结果
张三总监的工资是：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:@"王五"];
输出结果
张三总监的工资是：10000
李四经理的工资是：1000
王五员工的工资是：100
可以看到，【方式二】 没有改动原来的方法，而是在类中新加了三个方法，这样虽然也违背了单一职责原则，但在方法级别上却是符合单一职责原则，因为它并没有改变原来方法的代码。
示例总结
上面三种方式各有优缺点，那么在实际编程中，该采用哪一种呢？这个问题没有标准答案，需要根据实际情况来确定。
