单一职责原则

        本文参考书籍《设计模式之禅》；

      单一职责原则，简称SRP，原定义是：There should never be more than one for a class to change。

      也就是说一个类，一个接口有且只有一个职责，只负责一件事情。

      下面的截图是一个电话类图的设计过程：

       1：  这个接口的设计貌似是没有问题的，也是绝大部分项目在实际开发中会做的设计，但是请换一个角度来看，dial方法，hangup方法：一旦一个电话从按键盘到现在的触摸屏；dial方法从电话拨出功能增加了上网功能。按照书籍中所述：这两个方法实现的是协议管理，而chat方法实现的是数据的传送，协议接通的变化会引起这个接口的变化，但是数据传统也会引起这个接口或者实现类的变化。

       请看上面的这段话的逻辑的隐含逻辑：如果按照上述的接口或者实现类这样设计，符合现在或者说一段时间以内的业务需求是可以的，但是一旦业务场景或者说技术进步发生了变化，那么这段代码就必须要发生变更，换句话说这段代码的扩展性很不好。

       OK，有了上面的思考之后，请看下面的这个类图：

       看到这个设计，你想到什么？想法很好，但是你以为我很傻吗？这样就平白无故的多增加了两个类，把抽象层又多了一层，好起来高瞻远瞩，但是不切实际。

         恩，有道理，那我们来看看下面的这个类图：

         

          看到这个图，是不是觉得好了很多。

      

          好了，到这里我们应该可以明白了吧。单一职责原则有什么好处：

          1、类的复杂度降低，实现什么职责都有清晰明确的定义；

          2、可读性提高；复杂度降低，那当然可读性提高了；

          3、可维护性提高，可读性提高，那就更容易维护了；

          4、变更引起的风险降低；也就是说提高了扩展性和可维护性。

       看到这里，可能我们觉得已经很清楚了，但是请看明白：依据职责来划分类这个标准是不可量化的，就像说是管理学中讲的什么样的公司组织架构是最有效率的，但是这种结构在不同的公司，不同的公司环境，不同的公司成长阶段组织架构必然会不一样。

 

        注意：单一职责原则提出了一个编写程序的标准，用“职责”或“变换原因”来衡量接口或类设计的是否优良，但是职责和变换原因都是不可度量的，因项目而已，因环境而已。

       这个招式是这样的，但是招式后面的思想或者武功的精髓，还要静下来细细琢磨。