软件设计原则和模式--------单一指责原则
对于一个类，应该仅有一个引起它变化的原因，很简单，如果一个类承担了多余一个的职责，那么引起它变化的原因就会有多个。也就等于把这些职责耦合在了一起。当然了一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。最终的结果就是这种耦合会导致一种脆弱的设计。例子：Retangle类有两个方法。一个方法把矩形绘制在窗体上，另一个方法计算矩形的面积:
多余一个的职责的情况
有2个不同的程序使用矩形类，一个是计算几何学方面的，此时Rectangle类会为次几何学程序提供帮助，它从来是不会在窗口上绘制矩形的。而另一个程序是有关图形学方面的，他可能也会进行一些几何学方面的计算，但是它肯定会在窗口上绘制矩形。
所以说这个设计违反了单一职责原则，就是矩形类具有2个职责：1：提供了一个矩形几何形状的数学模型；2：把矩形的一个图形用户界面绘制出来。这样的设计可能会导致一个地方的改动会带动其他的地方的一列改动。一个比较好的设计是把这两个职责分离到两个完全不同的类中。如下：
什么是职责？
可以理解为：变化的原因，如果你能想到多与一个的动机去改变一个类，那么这个类就具有多于一个的职责。有时候我们很难做到这一点，都是习惯以组的方式去考虑职责。如下面的接口看起来很合理：该接口所声明的4个函数确实是调制解调器所具有的功能：
{
void dial(string pno);
void hangUp();
void send(string c);
void recv();
}
然而，该接口中却显示出两个职责，第一个职责是连接管理[dial；hangUp]；第二个职责是数据通信[send；recv ]，问题是这两个职责应该被分开吗？这得依赖于应用程序变化的方式了。如果程序的变化会影响连接函数的签名，那么这个设计就具有僵化性的味道。因为send；recv类必须要重新编译。部署的次数常常会超过我们希望的次数。在这样的情况下，需要把这两个职责分离开。但是另一方面，如果应用程序的变化方式总是导致这两个职责的同时变化，那么就不必分离他们了。
总结：单一职责是所有原则中最简单的之一，也是最难正确运用之一。我们会自然的把职责结合在一起，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
