单一职责原则（Single Responsibility Principle，简称SRP），就是我们在设计一个接口、类或者方法的时候，需要保证它的职责是单一的。先举一个不符合单一职责原则的例子：
@protocol IUser <NSObject>
@property (strong,nonatomic) NSString *name;
@property (assign,nonatomic) NSInteger age;
- (void)eat;
- (void)sleep;
@end
上面接口定义了一个用户，它之所以不符合单一职责原则，是因为它同时实现了用户的属性（name，age）和用户的行为（eat，sleep）两种职责。为了符合单一职责原则，我们应该把它们分开：
定义用户属性的接口：
@protocol IUserInfo <NSObject>
@property (strong,nonatomic) NSString *name;
@property (assign,nonatomic) NSInteger age;
@end
定义用户行为的接口：
@protocol IUserAction <NSObject>
- (void)eat;
- (void)sleep;
@end
接口定义好后，下面我们来使用这些接口来定义我们的用户类。为了让我们的类也符合单一职责原则，按照上面的思路，我们需要定义一个表示用户属性的类和一个表示用户行为的类：
表示用户属性的类：
@interface CUserInfo : NSObject<IUserInfo>
@end
表示用户行为的类：
@interface CUserAction : NSObject<IUserAction>
@end
这样，一切都非常完美地符合单一职责原则了，但是，本来一个类就能实现的功能，现在为了符合单一职责原则，硬生生地写成了两个类，在使用的时候只能将它们组合起来用，人为地增加了设计的复杂性。所以，在实际开发中，你很难看到一个单一职责的类，因为很难做到，也没有必要这样做。我们只需要保证接口的职责是单一的就可以了。所以，我们的用户类可以设计为：
@interface CUser : NSObject<IUserInfo,IUserAction>
@end
单一职责原则的好处
单一职责原则的好处如下：
- 降低类的复杂性。每个接口、类或者方法负责什么职责都非常明确；
- 提高代码的可读性；
- 提高代码的可维护性；
- 降低变更引起的风险。在开发中，变更是必不可少的，如果接口是单一职责的，那么一个接口的修改只对相应的实现类有影响，这对系统的扩展性、维护性都有非常大的帮助。
总结
如果接口、类或者方法都符合了单一职责原则，那么你的代码质量肯定是很高的。但是值得注意的是，如果要做到类的职责是单一的，那么很可能会导致类的数目大增，人为地增加复杂性，得不偿失。所以，建议接口和方法一定要做到单一职责，类的设计尽量保证单一职责就好。
此外，单一职责原则存在争议的是关于“职责”的定义，“职责”没有一个可以量化的标准，这跟具体的需求，甚至是个人的常识都有关系。
网友评论