因为够懒，所以我严守单一职责
其实想把6大原则放一起说的，但是写开了以后才发现，光一个原则就能扯出一大通东西来，还是分开说吧。
===========
哪里单一？
单一嘛，大家都懂的，只干一个事。
但是，哪里需要单一呢？只有类和接口？ 任何东西都要单一！ 容我给你从小了慢慢往大了扯~
变量要单一.
啊这个没疑问的吧，一个变量只干一件事，比如一个按钮不能又是播放按钮又是关机键。关机和开机放一起没关系，因为他们都是控制电源的。这里要提一点，既负责播放又负责关机这个设计只能说不好，但并不能说是错的。架构设计没有对与错之分！！！
方法要单一.
方法单一是单一这个原则最容易实现的一块。方法的单一体现在，一个方法干且只干下面类型中的一种事情：初始化的、View显示的、对象获取的、布尔判断的、逻辑分发的等等等。这是非常有利于代码阅读与代码修改的，后面我们详细讲。
接口要单一.
接口的不单一设计体现在：某个实现类不得不以空方法的方式实现一个接口里的方法。接口的一个功能是做隔离和解耦，接口的方法都是public，一个无用的public方法暴露给依赖类，对依赖类来说很容易产生误解的一件事，“你给我的，就是我都能用的，不要口头告诉我不要调用你这个方法。”
类单一 ？
这个地方就打问号了。为什么呢？因为类的单一太难界定了。连老外的大神都说了：“This is sometimes hard to see”。这个有时很难说。举例子吧：
我设计了一个在ListView为空的时候对用户提示的控件，我想把它设计成自给自足的，所以在这个控件里面做了逻辑判断，是不是为空呀，为什么为空呀。根据不同的判断结果，进行不同的样式展示。老大看了以后说不行了：“你这个东西设计的不单一啊！一个控件应该只负责显示，怎么能做业务逻辑处理呢？”我说：“这是一个单一的功能模块，不只是一个View。它是一个功能单一的东西，不是指责单一的。”
我俩谁对谁错？这个是争论不出来结果的。所以，还是看情况！
包要单一.
包单一有助于项目的开发，没有人愿意维护一个结构乱七八糟的项目。
如何做到单一？
说完了哪里单一，我们讲讲如何做到单一。单一说着很简单，但其实对于新手来说，并不是那么容易，因为实际业务太多样了，一定要讨论这个事情，不亚于哲学家开辩论会！！
大胆写，随便写。写完才能改嘛。
我有一个习惯，代码写完 3 ~ 5 次自Review。说来惭愧，只是担心被现在的同事和未来的同事嫌弃。因为知道自己会Review这么多次，所以不会考虑太多。（真心的，考虑太多就不用写了，计划赶不上变化）。等到写完了，Review之后你会发现很多问题，开始改，这一改，你就知道了，这样写才是更好的，下次就记住了。
而且优化代码是一件成就感爆棚的事情哦~
怎么改？捷径：消除重复。
当你的一段代码重复出现超过两次以后，你就要开始考虑是不是设计上有问题了，因为出现了超过两次，你很难保证，将来不会出现更多次。
对代码有追求的猿，是拒绝重复的！
方法级单一实现：将所有重复的代码段按上一节【方法要单一】中讲的类型分门别类的放到不同方法里。这是一件简单粗暴的事情，做完它，你就发现你的代码焕然一新。
接口接的单一实现：同样对于初级程序猿来说，接口的设计也是满路荆棘。讲几个经验吧。
类的单一：这个还是像上面的说的：This is sometimes hard to see。但还是有几个雷区是一定要避免的。
- 珍爱生命，远离业务。抽离所有的业务逻辑，单独管理，这些由产品经理决定的东西~珂珂！
- 继承是侵入式的，很可能让你类不知不觉多了一些不应该多的东西。
- 对于View控件来说，ListView是一个比较好借鉴的榜样。ListView本身只负责Item的显示和回收利用，Adapter负责逻辑，决定Item长什么样。
单一后的样子
最后我们讲讲单一以后的样子，看看你能不能交上一份好的成绩单。（话说这个成绩单应该能保证你及格吧？）
没有超过两次以上的重复代码段。（你看有多懒，不愿意重复写）
在你有需求变动的时候，只改一个地方就好了。（你看有多懒，不愿意多改几个地方）
暴露给依赖类的方法，都是可以用的。（你看有多懒，都不想动脑子）
（不要较真，某些情况真的是避免不了的。原则，有时也是用来打破的）
