面向对象的原则、模式、语言及框架（三）

[b]单一职责原则 [/b]
这个原则描述了内聚性：一个模块组成元素的功能相关性。单一职责原则描述了引起类变化的原则只有一个，而职责就是变化的原因，如果你能够想到多于一个动机去改变类，那么这个类就具有多于一个职责。
例如
[code]
class Rectangle{
public void draw();
public double area();
}
[/code]
如果这个类为两个不同的应用程序所使用：计算几何学方面的，它只需要提供计算面积的方法，图形绘制方面的，它可能只需要在屏幕上绘制自己。那么这个类就有了两个职责，这种设计违反了单一职责原则。当我们在计算几何学方面方面需要新的功能时我们需要修改这个类，
当在图形绘制方面修改这个类时也需要修改这个类。
这样我们可以把这个Rectangle分成两个：
[code]
class GeometricRantangle{
public double area();
}
class GUIRectangle(){
public void draw();
}
[/code]
这样当我们需要在计算几何学方面使用Rantangle时，我们直接使用GeometricRantangle，图形绘制方面直接使用GUIRectangle。
再看一个调制解调器的例子：
[code]
interface Moderm{
public void dial(String pno);
public void hangup();
public void send(char c);
public void recv();
}
[/code]
多数人会认为这个接口是合理的，但这个接口却承担了两个职责：一是连接管理；二是数据通信。而在大多数应用中，连接管理和数据通信往往是分开的。如果无论连接管理发生了变化还是数据通信发生了变化，我们都需要修改这个类，这就造成了编译和部署的次数会超过我们希望的次数，这个设计具有僵化的Bad Smell.这种情况下我们希望把这两个职责分离：
[code]
interface Connection{
public void dial(String pno);
public void hangup();
}

interface Channel{
public void send(char c);
public void recv();
}
class Moderm implements Connection,Channel{
//...
}
[/code]
虽然我们看到Moderm依然是一个杂凑物，似乎也有两个职责，但这是必须的，因为这是对Moderm 功能真实的抽象。但是，这样我们需要连接管理的时候，我们只依赖于Connection接口，当我们需要数据通信的时候只需要依赖Channel接口，谁都不需要依赖具体的Moderm.单一职责通常是针对提供给用户接口来说的，而实际类作为一个实际的对用物，有
多种职责可能是必须的，只要我们抽象出单一职责的接口，让其他的代码只依赖于这些接口就行了。
我们在企业级开发时经常遇到的情况是，在业务层写持久化规则，业务规则是经常变化的，而持久化规则通常是稳定的。如果不把他们分离，每次变化我们都要编译部署整个混合体，这只能是自找苦吃。通常的做法是使用DAO模式，分离出数据访问层，让业务层依赖于DAO接口，这样业务层发生变化时，不会影响 数据访问层，并且可以随时替换掉数据访问层的具体实现。
当然如果应用程序的变化总会导致这两种职责的同时变化，那么就不必分离他们，毕竟单一职责原则会带来一些复杂性，生成更多的接口。如果过度使用这个原则会造成过度设计的Bad Smell.