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

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

概念：有且仅有一种原因引起类的变更。
示例：如图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();
示例引申：如图1-3所示电话接口的设计，是否该接口的设计符合了单一职责原则？实际上它包含了两个职责协议管理和数据传输。dial和hangup方法实现的是协议管理，分别负责拨号接通和挂机；chat实现的是数据传输。如果协议发生了而变化以及数据传输的变化（如可以通话还可以上网）都会引起类的变化；这两个职责是否会相互影响？电话拨号我只关心能接通就行，甭管是电信还是网通的协议，电话接通后，也不用管传输的是什么数据，所以该两个职责业务上没有相互依存的关系，因此可以拆成两个接口如图1-4所示：



图1-3



图1-4
优点：

类的复杂性降低了；

可读性提高；

可维护性提高；

变更引起的风险降低
缺点：“职责”和“变化原因”不可度量，需要因项目和环境而异。
最佳实践做法为：接口一定做到职责单一，类的设计尽量做到只有一个原因引起变化