《设计模式之禅》六大设计原则（一）单一职责原则

• （一） 单一职责原则（SRP-SingleReponsibilityPrinciple）

1. 概念：有且仅有一种原因引起类的变更。
2. 示例：如图1-1简单的用户信息的维护此类图的设计则有着严重的缺陷，用户的属性和用户的行为没有分开，应该将用户信息拆成一个用户BO（Business Object），将用户行为拆成一个Biz（Business Logic）如图1-2所示
   
   
                                              图1-1                                                                                                图1-2
   使用代码示例为:
   IUserInfo userInfo = new UserInfo();
   //若要赋值，则认为是一个纯粹的BO
   IUserBo userBo=(IUserBo) userInfo;
   userBo.setPassword("abd");
   //若要执行动作，则认为是一个Biz
   IUserBiz userBiz=(IUserBiz) userInfo;
   userBiz.deleteUser();
3. 示例引申：如图1-3所示电话接口的设计，是否该接口的设计符合了单一职责原则？实际上它包含了两个职责协议管理和数据传输。dial和hangup方法实现的是协议管理，分别负责拨号接通和挂机；chat实现的是数据传输。如果协议发生了而变化以及数据传输的变化（如可以通话还可以上网）都会引起类的变化；这两个职责是否会相互影响？电话拨号我只关心能接通就行，甭管是电信还是网通的协议，电话接通后，也不用管传输的是什么数据，所以该两个职责业务上没有相互依存的关系，因此可以拆成两个接口如图1-4所示：
   
                    图1-3    
   
                                             图1-4
4. 优点：
   类的复杂性降低了；
   可读性提高；
   可维护性提高；
   变更引起的风险降低
5. 缺点：“职责”和“变化原因”不可度量，需要因项目和环境而异。
6. 最佳实践做法为：接口一定做到职责单一，类的设计尽量做到只有一个原因引起变化