[设计模式原则]第一回：单一职责原则

1.引言

单一职责原则（SRP,Single Responsibility Principle)，强调的是职责分离，在某种程度上是对职责的理解是构成了不同类之间的耦合关系的设计关键。

2.引经据典

核心思想：一个类最好只做一件事，只有一个引起它变化的原因。

单一职责原则可以看成是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少变化的原因。职责过多，变化的原因也就多，将导致职责之间的依赖，互相产生影响，从而极大的损伤其内聚性和耦合度。

一些理解：

所说的职责一般指功能，然而单一职责原则是由引起变化的原因决定，并非职责决定，这个要引起重视，不要会错意了。

一个类最好只做一件事，这是一个职责的粒度划分，可大可小，小到一个方法，大到一批，甚至关联到许多其它模块，只要是这个类的职责所在就行，就是所说的高内聚。

一个类最好只做一件事，事情越少越稳定，所以要设计的类尽量简单，也可以设计的复杂，平常总说，说的越多，错的越多，就是这个道理。

平时生活中所说的 “专心做一件事，而不是广而不精，这样才会做的更好”、“做你该做的，不该管的不要管，少管闲事，否则会惹麻烦的” 等等 都有这个规则的体现。

3.应用反思

看一个例子，如下：

//电灯
public class Light
{
public void Shine()
{
Console.WriteLine("灯泡亮了");
}

public void Black()
{
Console.WriteLine("灯泡黑了");
}

public void TurnOn()
{
Console.WriteLine("打开电灯");
}

public void TurnOff()
{
Console.WriteLine("关上电灯");
}
}

看到电灯对象里有四个方法，点开 和关闭电灯，还有电灯的状态输出，此时发现 电灯太霸道了，大部分灯没有这个开/关功能，当然有的有，不过这应该划分到开关的功能，电灯不具备这样的功能，电灯就是有一个 发光或者不发光，电灯越权了，开关会生气，我们添加一个开关，把职能分离出去，这时，电灯亮与不亮就靠开关了。

//电灯
public class Light
{
public void Shine()
{
Console.WriteLine("灯泡亮了");
}

public void Black()
{
Console.WriteLine("灯泡黑了");
}
}
//开关
public class Switch
{
Light light = new Light();

public void TurnOn()
{
Console.WriteLine("打开开关");
light.Shine();
}

public void TurnOff()
{
Console.WriteLine("关上开关");
light.Black();
}
}

这个例子平时肯定不会那样写， 只是这么个意思。

4.规则建议

关于单一职责的原则，我们的建议是：

一个类只有一个引起它变化的原因，否则应当考虑重构。

SRP由引起变化的原因决定，而不由功能职责决定，应该申时度势。

测试驱动开发有助于实现合理分离功能的设计。

查考资料 《你必须知道的.NET》