单一职责模式
疑惑
相信大家在开发中，一定或多或少遇见过一些代码量很多的类，里面包含着特别多的方法或者内部类，或者特别多的算法等。想要梳理清楚这个类的一些逻辑，可能要花费很多的时间，而且一旦需求有所改变，无论是想要快速定位到具体的算法然后修改，还是扩展都是难上加难。
如果一个类承担的职责过多，就等于将这些职责耦合在了一起，一个职责的变化可能会削弱或者一直这个类完成其他职责的能力，这种耦合会导致脆弱的设计。当发生变化时，设计会遭受到意想不到的破坏。
当然，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。其实要去判断是否应该分理出类来，就是如果你能狗想到多一个动机去改变一个类，那么这个类就具有多余一个的职责，就应该考虑职责分离。
单一职责
Single Responsibity Principle 简称SRP.
定义是：应该有且仅有一个原因引起类的变更。there should never be more than one reason for a class to change。这种单一职责不仅仅用在类上，也适用于接口，以及方法。比如通常来说修改用户密码的方法就不要和查询用户的方法放在一起。而且通常修改密码的方法也不会和修改用户基本信息的方法放在一起。
为了实现单一职责，我们需要做的就是职责扩散，就是因为某种原因，职责A被分为粒度更细的职责a1和a2。修改类a1不会引起a2的变化。
优势
- 降低类的复杂度，一个类只负责一项职责，其逻辑简单。
- 提高类的可读性，提高系统的可维护性。
- 变更引起的风险降低。
总的来说就是易维护，可扩展，可复用，灵活性好。