首页 > 代码库 > 设计模式六大原则（1）--单一职责原则
设计模式六大原则（1）--单一职责原则
定义：
一个类，只有一个引起它变化的原因。通俗的来说就是一个类只负责一项职责。
问题由来：
类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：
遵循单一职责原则，设计两个类T1和T2，T1负责完成职责P1，T2负责完成P2。当P1变动需要修改T1时不会影响T2；同理，当P2变动需要修改T2时不会影响T1。这样，T1与T2之间职责不同，独立存在，因此无论修改哪一项的实现功能都不会影响另一方的职责。
说到单一职责原则，很多人可能会不屑一顾，因为它实在是太简单了。稍微一个人即使他不懂设计模式，不知道单一职责原则，在设计类的时候也知道自觉遵守这一原则，因为这是常识，哈哈。在软件编程过程中，谁也不想因为修改了某个功能而使另外其他的功能出现问题，显然遵循单一职责原则很重要。既然这样，那又为什么很多经验丰富的程序员也会犯这个错误（违背单一职责原则）呢？这是因为有职责扩散。所谓的职责扩散是指由于某种原因，职责P被分化为粒度更细的职责P1和P2。
比如，类T只负责职责P，这是符合单一职责原则的。但是，由于需要变更或者是开发者的层次提高了，需要将职责P分化为粒度更新的职责P1、P2，按照单一职责原则，需要设计两个类分别完成职责P1和P2，但是由于实现P职责的代码已经写好的情况下，这样做就太浪费时间了。于是，直接在T类中修改添加，实现职责P1和P2，这样是比较简单的（显然，这违反了单一职责原则）。但是这样的风险就是由于职责扩散的不确定性，我们不确定是否将来职责P会扩展为P1、P2、P3…Pn。记住，在职责扩散到我们无法控制之前，要立即果断的将代码重构。
举例说明一下，比如用类描述动物呼吸这个场景（注意演示使用的类比较简单，实际应用的类要复杂得多），代码如下所示：
class Animal { public void Breathe(string animal) { Console.WriteLine(animal + "呼吸空气"); } } class Client { static void Main(string[] args) { var animal = new Animal(); animal.Breathe("猪"); animal.Breathe("狗"); animal.Breathe("牛"); animal.Breathe("羊"); Console.ReadKey(); } }
运行结果如下所示：
程序上线了，发现并不是所有动物都是呼吸空气的，比如鱼就是呼吸水的。这样一来，按照单一职责原则要设计两个类：陆生动物类Terrestrial，水生动物Aquatic，代码如下：
class Terrestrial { public void Breathe(string animal) { Console.WriteLine(animal + "呼吸空气"); } } class Aquatic { public void Breathe(string animal) { Console.WriteLine(animal + "呼吸水"); } } class Client { static void Main(string[] args) { var terrestrial = new Terrestrial(); terrestrial.Breathe("狗"); terrestrial.Breathe("牛"); terrestrial.Breathe("羊"); var aquatic = new Aquatic(); aquatic.Breathe("鱼"); Console.ReadKey(); } }
运行结果如下：
我们会发现如果这样修改花销是很大的，除了将原来的类分解之外，还需要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则，但花销却小的多，代码如下：
class Animal { public void Breathe(string animal) { if("鱼".Equals(animal)) Console.WriteLine(animal + "呼吸水"); else Console.WriteLine(animal + "呼吸空气"); } } class Client { static void Main(string[] args) { var animal = new Animal(); animal.Breathe("狗"); animal.Breathe("牛"); animal.Breathe("羊"); animal.Breathe("鱼"); Console.ReadKey(); } }
运行结果如下：
可以看到，这样修改时最简单的。但是，若有一天，需要区分呼吸淡水和海水的鱼，就要在修改对应Breathe方法了，这种修改直接可能会影响牛、羊等原来正确执行的参数，可能会出现羊呼吸水这样的结果。在这种代码级别上违反单一职责原则是最严重的错误，这个必须要严格避免，因为隐患最大。来看另一种修改方式，代码如下所示：
class Animal { public void Breathe1(string animal) { Console.WriteLine(animal + "呼吸空气"); } public void Breathe2(string animal) { Console.WriteLine(animal + "呼吸水"); } } class Client { static void Main(string[] args) { var animal = new Animal(); animal.Breathe1("狗"); animal.Breathe1("牛"); animal.Breathe1("羊"); animal.Breathe2("鱼"); Console.ReadKey(); } }
运行结果如下所示：
这种改动方法在原来的基础上添加了一个方法，在代码级别上违背了单一职责原则，但在方法级别上却遵循了单一职责原则。上面的这3种方式各有自己的特点，实际项目中该使用哪一种，这个真的不好说，要根据具体项目具体需求而定。个人建议就是：只有逻辑足够简单，才可以在代码级别上不遵循单一职责原则；只有类中方法足够少时，才可以在方法级别上不遵循单一职责原则。
上面介绍使用的例子比较简单，所以无论是在代码级别还是在方法级别违背单一职责原则都不会造成太大影响。但在实际项目开发过程中，实际应用的类要复杂的多，一旦有职责扩散发生，除非这个类很简单，否则一定要遵循单一职责原则来设计的好。
遵循单一职责原的优点有：
- 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
- 提高类的可读性，提高系统的可维护性；
- 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。