1、一个类，只有一个引起它变化的原因。应该只有一个职责。

每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。

例如：要实现逻辑和界面的分离。

SRP中，把职责定义为“变化的原因”。

如果你能想到N个动机去改变一个类，那么这个类就具有多于一个的职责。这里说的“变化的原因”，只有实际发生时才有意义。可能预测到会有多个原因引起这个类的变化，但这仅仅是预测，并没有真的发生，这个类仍可看做具有单一职责，不需要分离职责。

3、实例：

新建一个Rectangle类，该类包含两个方法，一个用于把矩形绘制在屏幕上，一个方法用于计算矩形的面积。如图：

4、Rectangle类违反了SRP原则。

Rectangle类具有两个职责，如果其中一个改变，会影响到两个应用程序的变化。一个好的设计是把两个职责分离出来放在两个不同的类中，这样任何一个变化都不会影响到其他的应用程序。

5、持久化：下图展示了一种常见的违反SRP的清新。

Employee类包含了业务规则和对于持久化的控制。业务规则往往会频繁的变化，而持久化的方式却不会频繁变化，并且变化的原因也是完全不同，所以把业务规则和持久化子系统放在一起的做法是绝对不应该的。

6、结论：

SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。我们会不由的把职责以组的方式形成一个类，其实软件设计真正要做的许多工作就是发现职责并把那些职责相互分离。