摘自维基百科：

在面向对象编程领域中，单一职责原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类>完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。

这个术语由罗伯特·C·马丁（Robert Cecil Martin）在他的《敏捷软件开发，原则，模式和实践》一书中的一篇名为〈面向对象设计原则〉的文章中给出。 [1] 马丁表述该原则是基于的《结构化分析和系统规格》[2]一书中的内聚原则（Cohesion）上。

马丁把功能（职责）定义为：“改变的原因”，并且总结出一个类或者模块应该有且只有一个改变的原因。一个具体的例子就是，想象有一个用于编辑和打印报表的模块。这样的一个模块存在两个改变的原因。第一，报表的内容可以改变（编辑）。第二，报表的格式可以改变（打印）。这两方面会的改变因为完全不同的起因而发生：一个是本质的修改，一个是表面的修改。单一功能原则认为这两方面的问题事实上是两个分离的功能，因此他们应该分离在不同的类或者模块里。把有不同的改变原因的事物耦合在一起的设计是糟糕的。

保持一个类专注于单一功能点上的一个重要的原因是，它会使得类更加的健壮。继续上面的例子，如果有一个对于报表编辑流程的修改，那么将存在极大的危险性，打印功能的代码会因此不工作，假使这两个功能存在于同一个类中的话。

最近在看《设计模式之禅》，第一个就是单一职责设计，文中介绍此设计是一步一步开始深入的。单一职责适用于接口、类、方法，但是实际使用却不是这样的，真正的做到单一职责原则是很困难的，至少接口实现单一职责原则是问题的。文中建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

如果想更好的使用这样原则，对业务要有透彻的理解，因为只有理解了业务，在编码实现的过程中才能更好的运用它。