就一个类而言，应该只有一个引起它变化的原因。
这里的所有观点摘抄自《敏捷软件开发原则、模式与实践》，原著Robert C. Martin，邓辉等译。
职责分离
如果一个类承担的职责过多，就等于把这些职责都耦合在了一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。
类比于人，一个拥有多个角色的人，假如他既要。。。
例如书中的Retangle类，就具有绘制矩形和计算矩形面积的功能。图中可以看出，这两个功能分别由不同的应用来使用。
问题
如果我只是一个计算矩形面积的程式，并没有图形界面，理论上不需要引入绘制图形的GUI库（GUI的库一般比较大并且有很多依赖）。但是由于Retangle类具有绘制矩形的功能，所以势必要引入GUI库。对于C++来说就需要连接GUI的代码，这会浪费编译、链接以及消耗部分的内存。如果是Java程序，GUI的.class文件就必须被部署到目标平台。
如果GraphicalApplication的改变导致Rectangle也发生了变化，那么，这个变化会迫使我们重新构建、测试以及部署ComputationalGeometryApplication。
解决方案
一个较好的设计是把这两个职责分离到如下两个不同的类中。实现解耦。
可以看到，计算矩形面积的应用，只需要调用Geometric Rectangle来计算，这时候就不需要用到GUI库了。
什么是职责
职责被定义为"变化的原因"。如果有多个导致类变化的原因，那么这个类就具有多于一个的职责。
很多时候，我们很难去区分到底是否具有多个职责，是否有多个原因引起了累的变化。下面通过一个modem的类，来说明什么情况下会区分出职责。
考虑如下的代码：
interface Modem {
public void dial(String pno);
public void hanup();
public void send(char c);
public void recv();
}
可以看出这个类中包含了两个部分，一个是连接处理，一个是数据通信。
那一定要进行拆分么？
其实不一定，是否需要拆分取决于变化。
- 当变化发生，只影响其中一个职责，那就需要拆分
- 如果变化都影响到这两个职责，那就不需要拆分
