来自维基百科：
单一责任原则指出，每个类都应该有一个 单一责任，而该责任应完全由 由类封装。
这是否意味着实现多个接口违反了这一原则？
我会说不是本身。一个类可以有一个职责，但在这个过程中做多件事，并为它履行职责需要做的每组事情实现一个接口。
此外，Java中的接口可以用来说明类具有哪些属性（例如，Comparable和Serializable），但不能真正说明类的责任。
但是，如果一个类实现多个接口，每个接口对应于一个责任，那么这将违反该原则。
也许吧，但不一定。
接口不是责任。有一种非常强大的架构模式，它将接口视为定义对象在应用程序中可能扮演的角色。
想想这意味着什么。你可以有一个具有各种接口的Person类（让我们使用 .net 约定进行命名）
class Person : IAmAStudent, IDrawSocialSecurity, IAmACitizen {
public SocialSecurityNumber getSocialSecurityNumber() {
return this.ssn;
}
private SocialSecurityNumber ssn;
public Person(SocialSecurityNumber ssn) { this.ssn = ssn; }
}
现在显然这不能违反SRP。它显然只有一个改变的理由——如果人和社会安全号码之间的关系发生变化。然而，该对象实现了许多接口，并在应用程序中扮演多个角色。
现在，如果您正在实现多个公开不同功能的接口，则可能会违反SRP，但这也可能是一个判断电话。单一责任原则是实现松耦合的一个很好的经验法则，但这并不是城里唯一的理想。还有高度的凝聚力，表明相关代码应该共存。这两者从根本上是矛盾的（尽管通常有办法实现良好的平衡）。因此，您可能会合理地朝着一个方向做出选择，并有意识地决定违反 SRP。
最终，SRP和所有SOLID规则更多的是确保你沿着某些路线思考，而不是每次都盲目地遵循它们。
单一责任"取决于抽象级别。例如，一个复杂的系统，从系统级别考虑它，可能有一个责任。例如，电视系统的职责是显示视频图像。在下一个较低级别，该系统由子系统、监视器、动力单元等组成。在这个级别上，这些单位中的每一个都有自己的责任。
同样，一个类，在一个层面上可以被认为是具有单一的责任。但是，在较低级别，它可能具有执行其部分作业的其他组成模块（类，接口等）。例如，学生类的职责是表示学生抽象。但是，它可能有另一个单元（一个班级）来表示学生的地址。
这样，使用多个接口本身并不违反面向对象的原则。