想要精通设计模式，必须要先搞清楚设计模式的六大原则。
在开始设计模式之前，先来谈谈设计模式的六大设计原则，第一个便是单一职责原则(Single Responsibility Principle)了。
单一职责原则定义
There should never be more than one reason for a class to change.
这句话意思很简单，不应该存在多于一个导致类变更的原因。通俗来说就是，一个类应该只有一项职责，不会有多个原因导致类发生变更。
问题由来
我们设计这样一个接口
public interface IUserInfo {
void setUsername();
void changePassword();
}
很明显看到这样一个接口，谁都会觉得有问题，用户属性怎么可以和用户行为放在一起。肯定应该是用户属性放一起，用户行为放一起啊。
单一职责解决问题
对啊，根据这样的想法，我们把刚刚的接口拆成两个接口。
public interface IUserInfo {
void setUsername();
}
public interface IUserBiz {
void changePassword();
}
其实这就是单一职责原则。
有人可能就要说了，这也太简单了吧。对啊，对于一个从未接触过设计模式的小白来说，在设计接口的时候，都会去这么设计的。
是啊，真的很简单，可是有时候却又十分的难去实现，因为职责的划分很难，就比如手机打电话来说
public interface Iphone {
void dial(String phoneNumber);
void chat(Object o);
void hangup();
}
这里我们定义一个手机接口，我们来划分职责，接通和挂断应该是通信协议上的，而聊电话则是数据传输。那按照单一原则来说，我们应该给它们也拆到两个接口中去，但是拆开之后呢，我们会发现，当我想打电话的时候我需要将他们再组装到一起，这样反而是增加了系统的复杂度，我想平时遇到类似情况的时候，我们都是放在一个接口中的。
另一方面，职责扩散，就是由于某种原因，导致原来单一的职责变成了若干了更细粒度的职责。这时候如果再去拆分，代价还是比较高的。
优点
单一职责原则会有以下优点：
- 降低了类的复杂度，实现什么职责都有清晰明确的定义。
- 提高了可读性。
- 提高了可维护性。
- 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。
总结
看到过大佬有这样的说法，只有逻辑足够简单，才可以在方法级别上违反单一职责原则，只有类中方法数量足够少，才可以在类级别上违反单一职责原则。
单一职责原则看起来很简单，做起来却很难，单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类的设计是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。
因此对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。