设计模式六大原则： 一个萝卜一个坑 -- 单一职责原则

形形色色的代码接触多了，越发意识到 面向对象 这个被人说烂却鲜有用好的概念的重要性。之前看了《大话设计模式》也只是匆匆一瞥，没有敲代码或者记博客，这次连着《Android 源码设计模式解析与实战》一起学习，总结记录下来。

设计模式流传江湖许久，据说有 23 式，而万物归宗皆有其律，这些繁杂的模式总结出来就是如下 6 大原则。

1. 单一职责原则
2. 开放封闭原则
3. 里氏代换原则
4. 依赖倒置原则
5. 接口分离原则
6. 迪米特原则

在氛围好、发展快的公司、部门，每项工作都有对应的人来完成，你去了就是流水线上的一部分，只要努力做好自己的工作，有需要了调下面提供的接口，写好了再把接口暴露给别人，哪怕你身体不舒服请假了，你的这块东西也很容易找到别人替换。
然而在另外一些公司、部门，由于资金、规模或者管理的问题，往往一人顶 N 个人使，两天一需求、一周一迭代，人一累了免疫力下降，容易写 bug 不说还容易得病，结果一个员工得病了或者辞职了，这个项目就进行不下去了。

对比上述两种，一个萝卜一个坑还是优势很大的，毕竟软件开发过程就和创业公司的人力一样，会不停的有变动，一旦把鸡蛋都放到一个篮子里，容易全军覆没。

所以这时就用到了 单一职责 SRP(Single Responsibility Principle)

从名字就可以看出，单一职责强调的是接口、类、方法的“专一性”。这种“专一性”在我们编码时怎么体现呢，那就是尽可能的让你的类、方法、接口的功能原子化、简单化，举个栗子：

假设你承包了一个小区的物业，小区户主很多，每天有大量的辣鸡产生，现在需要几个人来负责收拾物业的辣鸡，打造五星级清洁物业。你参考这种情况写个物业清洁类。

物业清洁需要做的事很多，比如楼道清洁、马路清洁、垃圾箱拜访清洁、垃圾外送、定时杀毒等等。一不小心你写的类可能就是这样：

长长的类啊，看着就头疼，仔细看会发现，其中有些职责还有关联，比如保洁员的工作进行后，清运员才有垃圾可以运输，如果保洁员干一半罢工了，清运员的工作也得耽搁。看着就乱，还容易出错。

我们知道，效率最高的工作方法就是职责分清，你干你的，我干我的，只有在需要交流的时候把我需要的东西给我就行，我不用管你怎么做的。同样，代码最干净的写法就是把那些又长又复杂的类、方法都拆开，按功能、模块分成一个个小组织。然后互相留个接口就好了。这样不管你内部怎么变动，只要能给我提供功能就 ok 了。这就是单一职责的意思。

回到之前的问题，我们采用单一职责原则，把物业清洁进一步细分，分为管理、保洁、清运三部分，然后每部分要做哪些任务都列个一二三四：

这样分成三个模块类，每个类中又有不同的职责方法，看起来清爽干净。实际工作时，也不会由于脏在一起不好分离、不好更换。

工程师可以不断审视自己的代码，根据具体的业务、功能对类、方法进行拆分，这是优化代码的第一步。

如果一个类承担的责任过多，就等于把这些责任的风险也承担了过来。其中任意 一个的变化都可能对整体造成影响。应该找出变的和不变的，进行分离。

软件设计真正要做得内容之一就是发现职责，并把这些职责相分离（ASD）

《大话设计模式》