<Java设计模式>---单一职责原则

1. 什么是单一职责原则

顾名思义就是一个职责嘛，完整的来说，就是一个接口、类和方法负责的功能是单一的，简单的。

2. 生活中的运用

其实，咱们生活中，有很多这样的例子，就拿手机厂商造手机来说，为了完成一部手机的制造，需要有生产cpu的、生产显示屏的、生产主板的、生产外壳的、生产麦克风的…各种的机器。那么每一种类型的机器就会生产这一类产品，不会生产其他的产品，这种进行单一产品生产的功能，就是单一职责的具体表现。

3. 这种原则的优点

那么为什么要这么做呢？当然不是吃饱了撑的，下面就来看看这样做有什么好处。
* 降低类的复杂性，有什么样的职责都是清晰明确的。
* 可读性提高，复杂性降低，可维护性提高。
* 应对将来变更的风险能力提高。

咱们就来反面来验证这3个优点，假如制造手机是一个牛掰的机器，这边把原料放进去，另外一边手机就出来了，那么这台机器就包含了很多的功能，生产cpu，生产显示器等等，全一机器干了，可想而知这台机器里面将是多么的复杂，假如这台机器生产外壳的功能坏掉了，那么这个庞大的机器将不能继续生产手机了，只能等待维修人员了，如果按照单一职责的机器来进行生产，那么我只要将生产外壳的机器换掉，就可以继续生产手机，这样应对风险的能力将大大提高，另外就拿后期的维修机器来说，单一职责的机器维修的效率也是很高的。

4. 菜鸟时代的Activity

当年写Activity的时候，会把对View的操作，对数据的处理，以及和其他Activity的交互逻辑全都写到一个Activity里面，到最后这个Activity一共1000行代码，当然也有比这还多的，于是吭哧吭哧把这样的功能完成了，这个时候产品经理说：“小王，这个功能目前有点变动，换成XXX这样的。”，估计，你当时掐死产品经理的心都有，算了，为了珍惜生命，也是就忍了，就开始默默的修改庞大的Activity，以及与之相关的类，等你改好了，发给测试，测试人员说：

没办法谁叫他是产品经理的呢，就需要改动很多的代码，一旦发生了bug，还需要从前往后的排查，兼职让人苦不堪言，那么在看看现在的MVP这个结构，不就这种单一职责的原理嘛，各自负责各自的，虽然类的数量增加了，但是结构条理清楚，面对将来业务的修改也是很方便，找bug也不费事了，最重要的是团队的分工合作。

5. 思考

理论是枯燥的，但是将理论和生活结合在一起，将大大提高对理论的理解。