1.定义
有且只有一个原因引起类的变更 There should never be more than one reason for a class to change.
2.代码分析
interface Iphone {
//拨打电话
public function dial();
//通话
public function chat();
//挂电话
public function hangup();
}
问题：
这个接口有两个职责：一个是协议管理（拨打电话和挂电话），一个是数据传送（通话），两个变化的原因在一个接口里了，所以不符合
整改为
interface IConnection {
//拨打电话
public function dial();
//挂电话
public function hangup();
}
interface IDataTransfer {
//通话
public function chat();
}
class Phone implements IDataTransfer,IConnection {
public function dial()
{
}
public function hangup()
{
}
public function chat()
{
}
}
3.意义
1.类复杂性降低，每个接口实现什么指责明确定义，不干其他工作
2.类的可读性提高，因为复杂度降低
3.类的可维护性提高，因为可读性提高
4.变更引起的风险降低，变更必不可少，如果单一职责实现的好，一个接口的修改只对相应的实现类有影响，对其他的接口无影响，例如上边的电话如果 换了数据传送的网络由移动变为联通，并不影响其他只实现协议管理的实现类。
4.注意
1.单一职责原则提出了编写程序的标准，用“职责”或者“变化原因”来衡量接口设计是否优良，但是这两点都是不可度量的，因项目而异，因人而异
2.过分的细分会给实现类的方式以及维护添加麻烦，本来一个类可以实现的，非要两个类聚合或组合在一起
3.不光体现在类和接口里，方法也同样可以落实这个原则，比如不要把修改密码的方法放进修改用户信息的方法里，要不这个方法的颗粒度太粗，不要让别人来猜这个方法可能是用来处理什么的
5.最佳实践
建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化
6.新的实践场景，领导让你写一个订单的支付类，但是支付前要有一个机制就是说不允许同样的用户在短时间内支付五次以上
7.再举一个日常生活中的例子：
你做了一个今日规划如下图
1.当你的领导在今天结束的时候，要看你的计划完成度，但是你只学习了一个工厂模式，你能打勾吗？显然不能啊，这时候你老大就看不明白了，感觉你这小子俩都没学，其实你也挺冤的，如果你拆成了两个是否你的情况就会稍微好点。至少少打50大板吧！
2.现在又变了，每天工作很多，学习计划适量减少，现在是两个学一个就行，但是没说学习哪个，如果你要改每日计划的话，是不是要改为 把和改为或，但是这又不清晰呀，老大还是看不出来你学习了哪个，学没学。索性改为如下：
晚上的时候学习了哪个给哪个打勾，没学习的删掉，或改为明日计划，是不是就好很多！
