本文为"设计模式之禅"读书笔记
单一职责原则
一个类或者一个接口只负责一件事情，单一职责适用于接口、类、同时也适用于方法、一个方法尽可能做一件事情。
举个例子说明怎么在实践中考虑单一职责原则
中国女性从男权社会中挣脱出来之后，有了自己的事业。那么矛盾就出来了，在之前，女性主要负责在家里做后勤工作，现在即要负责上班，又要负责做家务，没有那么多时间经历兼顾那么多事情。
那么我们可以简单的将上班和做家务两个职责分开，
如请一个保姆专门帮忙做家务（或者找一个老公全职帮忙做家务），女性自己只负责工作。
或者也可以选在在家里做全职太太，放弃工作的职责。
这种把一个人的职责，拆分成两个专门的人负责的职责，就依赖单一职责原则，就是专门的人做专门的事，能提高每个人的工作效率。
单一职责原则的定义：应该有且仅有一个原因引起类的变更。
我们再来看下书中作者的举例，日常用的电.话，电.话通话的时候有三个过程发生，拨号、通话和回应、挂机。
其类图如下
public interface IPhone {
// 拨通电.话
public void dial(String phoneNumber);
// 通话
public void chat(Object o);
//通话完毕，挂电.话
public void hangup();
}
这个类在我们看来已经接近完美了，我们日常写代码的时候也会这么写。但是从理论研究上还可以拆！
分析一下每一个方法涉及的东西： dial和hangup()两个方法实现的协议管理，分别负责接通和挂机。 chat()实现的是数据的传输。就是识别语音转换成模拟信号、数字信号 传递到对方， 和接收对方的模拟信号、数字信号转换成语音。
那么协议的变化会引起这个接口或者实现类的变化，数据传送的变化也会引起这个接口或者实现类的变化，两个原因引起接口或者类变化，就不符合单一职责原则的定义了
拆类图！
看上图，将功能拆分为协议管理和数据传输。看起来更加清晰了。
但是Phone类要把ConnectionManager和DataTransfer组合到一起才能使用。这种强耦合关系似乎增加了类的复杂度，多了两个需要维护的类。我们把中间两个类去掉，修改成这样的，如下图：
phone实现了两个接口，来完成电.话功能。但是phone就由两个原因引起的变化。
看到这里，我们觉得这个例子会有些自相矛盾。
但是我们是面向接口变成的，对外公布的是接口而不是实现类。通过现实的角度思考，如多维护两个类，增加类间的耦合，增加了系统的复杂性，将中间两个实现类去掉也是合理的。
上述例子，只是从理论上可以再进行一次这么细致的拆分，但是我们大多数人都会根据功能将电.话设计成 拨号、通话、挂机这样一个类中实现。也是合理的。
所以，作者向我们讲述了写代码的时候要遵循单一职责原则，但是也不需要在意那么多细节，大体上是符合的就可以，需要结合实际情况调整。
将接口，抽象类设计的尽量符合单一职责原则，具体实现类，结合实际情况调整。
我们总结下单一职责的好处
类的复杂性降低，每个类方法的职责有清晰明确的定义。
可读性提高，一个类一个方法只负责一个事情，可读性自然会变高。不过也需要同志们命名好接口、类、方法。
可维护性提高。
变更引起的风险降低，对于系统的扩展性和维护性都有非常大的帮助。
单一职责适用的地方，类，接口，方法。
尤其是方法，不要把所有的事情放到一个方法里面处理，单纯点好。这样别人在使用的时候不用再重新写一份。
