在我们工作当中，常有人抱怨自己的工作任务重，压力大。每天有许多的任务要做，一整天看起来一直都很忙，并加班到很晚，但是最后达成的效果并不理想，搞得自己焦头烂额，惨不忍睹，还要受到领导的指责。与其同时做许多事，都做的的一般般，还不如只专注做一件事做到极致。在现实生活中，如果我们每人只做一件事只承担一项职责，那么肯定可以把这件事把这项任务做的更好。一个个类组成的代码世界里，是不是一个类也只负责一个职责，可以使这个世界更整洁有序呢？
单一职责原则Single Responsibility Priciple，说的就是一个类的职责应该只有一个。看起来是不是很好理解，但是再看看SRP的原文解释是什么“There should never be more than one reason for a class to change.”一个类不能有两个以上包括连个原因引起变化。字面翻译大家都懂，但是具体是怎么一回事呢？比如一个人要吃饭、睡觉、上网，如果我们把单一职责中的职责字面理解为吃饭、睡觉、上网，那么是不是这里有三个职责了，是不是要把这三件事分离在不同的类当中呢？但是用原文定义中的职责变化原因，再看吃饭、睡觉、上网三件事，其实吃饭、睡觉对于一个人来说一般不会发生变化，真正变化的只有上网这一件事，即只有上网发生变化，这个人才会做出变化，此时就可以理解为这个人是符合单一职责原则。
单一职责（SRP），体现了类只应该做一件事，并且做好它，这样变化修改的理由只有他所做的事。良好的软件设计中系统是由一组大量的短小的类和他们之间功能协作完成的，而不是几个上帝类。这不就是面向对象中提到的高内聚低耦合中的高类聚么！
单一职责的优点：降低类的复杂度，提高代码的可读性，方便理解易于维护修改。
使用单一职责原则有一个问题，“职责”没有一个明确的划分标准，如果把职责划分的太细的话会导致接口和实现类的数量剧增，反而提高了复杂度，降低了代码的可维护性。所以使用这个职责的时候还要具体情况具体分析，找到中间的这个度。
三层架构模式实际上也体现了这一原则，它将整个系统按照职责的内聚性分为不同的层，层内的模块与类具有宏观的内聚性，它们关注的事情应该是一致的。例如，显示层就主要负责界面数据的交互先死，业务逻辑层就主要关注系统的业务逻辑与业务流程，而数据的持久化与访问则交由数据访问层来负责。若将职责在细分，就有了在三层架构上的多层架构。
ps：有时我看见有人把一个类写的少则上千行，多则近万，这就是所谓的“上帝类”，把所有的操作功能都放在一个类中，但是上帝是无所不能的，万能的马？。好吧！我又想到了这两天新闻报道的我们陕西现“全能神教”。
还记得上初中那会儿刚学反正法，我们数学老师让我们证明“上帝不是万能的！”。假设上帝是万能的，那么上帝能否找到一件自己做不到的事情呢？
