单一职责原则
单一职责原则(Single Responsibility Principle, SRP)中的 职责(Responsibility)被表述为“变化的原因”(reason to change)；SRP被表述为“一个类应该有且只有一个变化的原因”。
动机：对于设计原则的理解应该首先从它的动机入手，即遵循这个原则带来的好处是什么？对于SRP来讲，如果遵循“一个类应该有且只有一个变化的原因”是因，那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性，即降低适应变化的成本。牵一发而动全身，这显然是我们所不愿意看到的，所以我们会把这个类分拆开来，由两个类来分别维护这两个职责，这样当一个职责发生改变，需要修改时，不会影响到另一个职责。
代码示例
public interface IUserInfo {
void getId();
void getName();
void addUser(int id,String name);
}
这个接口将 业务对象 和 业务逻辑的内容放到了一个勒种，业务对象 和 业务逻辑 都会引起UserInfo 类的变化，违反了单一职责。
下面我们按照单一职责的要求拆分一下这个接口：
public interface IUserInfoA {
void getId();
void getName();
}
public interface IUserInfoB {
void addUser(int id,String name);
}
将 原接口 拆分为 A 和 B 两个接口，在需要相应的得操作时 去操作相应的接口就实现了我们所说的单一职责，也就是让引起他们变化原因只有一种,并且让相关性强的内容聚合在一个类内部。
拆分前：
拆分后：
优点
降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。
提高了代码的可读性。一个类简单了，可读性自然就提高了。
提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。
变更引起的风险变低了。单一职责最大的优点就是修改一个功能，对其他功能的影响显著降低。