注意:如果不想浪费时间，请一定要点我。
定义
就一个类而言，应该仅有一个引起它变化的原因。如果一个类中承担太多原则，会有以下缺点：
（1）一个职责的变化可能会削弱或者抑制这个类其他职责的能力。
（2）当用户需要这个类的其中一个职责时，不得不将其他不需要的职责包含进来，造成代码的冗余和浪费。
比如我们需要实现一个计算器系统，如果将加减乘除所有功能写在一个类中，如果要增加一个平方运算，或者修改已存在的功能，我们不得不修改这整个类，导致代码的复用性、可维护性和灵活性不高。优点
（1）降低了类的复杂度，一个类只负责一个职责。
（2）提高了类的可读性。
（3）提高了类的可维护性。
（4）变更引起的风险降低，修改一个功能时，其他功能所在的类的代码不需要变动，只需要修改该功能所在的类的代码即可，所以降低了对其他功能的影响。实现
软件设计真正要做的许多内容，就是发现职责并把这些职责分离开。如何判断是否要去分离出类，那就是如果你能想到多余一个的动机去改变一个类，那么这个类就具有多于一个的职责。一个类或者模块应该有且只有一个改变的原因。-
举例
比如我们的计算机，如果将计算机的功能都写在一个类中，那么修改或增加一个新功能时，我们必须重写这个类。
电脑
这样设计的话，每次电脑的任何一个功能发生变动，我们不得不重新购买一台新的电脑来使用这些新功能，这样设计不满足单一职责原则，因为显示器的变更，存储器的变更都会造成电脑类的改变，所以我们应该让该类进行分离。
新电脑
注：单一职责同样适用于方法，如果一个方法处理的事太多，会变得臃肿，难以维护。
