设计原则之单一职责原则

定义：一个类只负责一项职责，应该只有一个能引起它变化的原因。

问题：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常
     的职责P2功能发生故障。

解决：分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；
     同理，当修改T2时，也不会使职责P1发生故障风险。

举个栗子：介绍几种动物的栖息地和食物，这里边有两项职责：栖息地和食物。

用一个类Recommend介绍牛生活在陆地上，吃的是青草；羊生活在陆地上，吃的是青草。

运行后的结果是：

以上，类Recommend负责两个不同的职责：职责P1(动物)，职责P2(栖息地)，当职责P1发生改变，比如增加一个动物猪的时候，猪吃的不是青草，
那么我们就需要修改类Recommend，修改的方式有两种：

一是将类Recommend分解成类Recommend01和类Recommend02，如下：

然后在SRPFragment中分别调用：

运行后的结果是：

可以看出，将原来的类Recommend进行分解的做法，不仅修改的花销很大，还需要修改SRPFragment中的代码，所以不推荐。
我们能不能直接修改类Recommend呢？
二是在类Recommend的rede方法中加个判断，来区分吃青草的牛羊和吃五谷杂粮的猪：

运行后的结果是同上。
如此修改要简单得多，但当我们再加一种动物鱼的时候，又要去修改类Recommend中的rede方法，假设rede方法很复杂，那么就会对
原有的方法带来风险。
所以我们就要用到单一职责原则来解决这个问题，在类Recommend中添加一个新的方法用于介绍鱼的栖息地和食物，这样不会影响到
之前的功能了，如下：

运行后的效果是：

可以看到，这种修改方式没有去改动原来的方法，所以不会影响到原有功能的使用，在方法级别上是符合单一职责原则的。

原则：如果一个类承担的职责越多，那么它被复用的可能性就越小，并且一个类承担的职责过多的话，这些职责就会耦合在一起，
     当其中一个职责发生改变时，就可能会影响到其他职责的运作，这样的话势必会影响到后期功能的优化或扩展。
     将这些职责进行适当地分离，将不同的职责封装到不同的类中，注意的是对于那些总是同时发生改变的多个职责，可将
     它们封装在同一类中。

优点：高内聚，低耦合。可降低类的复杂度，提高类的可读性，提高系统的可维护性，在一定程度上降低变更引起的风险。