一、单一职责原则
什么是单一职责原则呢？--应该有且仅有一个原因引起类的变更。
there should never be more than one reason for a class to change.
举例：【来自设计模式之禅】
IPhone:
dial 【拨号】
chat【通话】
handup【结束】
上面是一个正常的通话接口:拨号、通话、结束
但是你会发现能够引起这个变化的有两个，一个是操作：拨号，挂电话，还有一个就是通信，所以修改如下：
IconnectManager【interface】
void dial
void hangup
ITransferData 【interface】
void chat
然后用两个类去实现它
class ConnectManager
class TransferData
这样又太过于繁琐，因为打电话这一个动作phone 必须需要上面两个同时实现，就是一个手机类需要把ConnectionManager和DataTransfer组合在一起才可以使用。组合是一种强耦合，你和我有共同的生命周期，所以下面这种设计才是完美的。
所以下面这种设计才是简介而通用:【phone类同时实现他们两个接口，吧两个职责融合在一个类中】
class phone implement ITransferData,IConnectMamager
总结单一职责的好处：
- 类的复杂性 降低，实现什么职责都有清晰明确的定义
- 可读性提高，复杂性降低了，那当然可读性就提高了
- 可维护性提高，可读性高，那当然更容易维护了
- 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这样的系统扩展性，维护性都有非常大的帮助。
单一职责适用于接口，类和方法。但是现实中由于成本，工期等众多因素，类的设计很难实现单一职责。所以对于单一职责的建议是：接口一定要做到单一职责，类的设计尽量做到单一职责。
