定义：单一职责原则，英文全称Single Responsbility Property。怎样的类设计才称的上符合单一职责原则呢？一句话：应该有且仅有一个原因引起类的变更(There should never be more than one reason for a class to change)。这句话看起来文绉绉，但是等下结合例子就会发现，这句话可以贯穿单一职责原则的始终。
为什么说单一职责原则是魔性的？因为类的职责实在是难以划分，没有严格的标准导致了没有唯一的答案。所以当你想和某个人吵架时，只要去问他：“你设计的类符合SRP吗”？保证你争个300回合，酣畅淋漓却不分胜负。
首先我们看看下面这个每个人都写过的类：
看了一遍这个接口是不是觉得怪怪的？是不是觉得有些地方不对劲，和自己写的有些差别？如果你说没有啊，我平时就这么写的，那么兄弟，你凉了。仔细看，我们发现这个用户IUserInfo接口里既有和属性相关的方法如setUserId()，又有业务逻辑在里面如changePassword()。属性和逻辑没有分开，这很糟糕，我们现在把属性和业务逻辑分开来：
这样是不是很清晰，IUserBo只和属性相关，IUserBiz只和业务逻辑相关。这里我们让IUserInfo继承了这两个接口，当我们需要使用到其中一方时，我们需要做个转换：
IUserInfo userInfo=new UserInfo();
IUserBo userBo=(IUserBo)userInfo;事实上，我们更倾向于单独使用这两个接口：
这样，两个接口就完全符合单一职责原则了。是不是觉得太简单了？如果这个时候是类，会不会还是这么简单呢？
假如小明要去购物Shopping，这个Shopping包含挑选商品(select）和付款(pay)两部分,如果按照SRP考虑的话，挑选过程和方式是变化的，付款过程和方式也是不唯一的，那我们是否应该将Shopping类分解为两个类:
如果把购物这个类细分，那我们就会考虑：付款类是否也需要细分？一分二，二分四，子子孙孙无穷尽也。生硬的按照单一职责原则会导致类数量的剧增，反而给维护带来了负担，增加了系统的复杂性。
所以这里可以得出一个有效的结论：对于接口一定要做到单一职责原则，对于类要尽量做到单一职责原则。
SRP不仅对接口、类有效，对方法同样有意义。在设计函数时，应该尽量让一个函数处理一个问题，比如这个方法是用来修改密码的，就不应该也可以修改地址。
如果我们在开发的过程中时刻考虑SRP，那么以后受益的不仅是我们自己，还有我们的同事，领导，公司。
这里我给出一个类，大家思考下是否符合SRP原则？我们在下一节分析。
注：dial()：拨号方法 chat()：通信过程 hangup：挂断方法
