单一职责原则理解起来比较容易，指的是一个模块（类，方法）只实现一个功能，但是实际应用起来不是特别容易，主要的问题点在于如何判断是否满足单一职责原则。要判断是否满足单一职责原则，可以从变化的角度来考虑：
1）一个模块只有一个变化的原因
2）一个模块应该对一类且仅对一类行为者（actor）负责
一个模块最理想的状态是不改变，其次是少改变。
我们可以从以下几个方面来理解单一职责原则：
1）需要理解封装，知道要把什么样的内容放到一起
2）需要理解分离关注点，知道要把不同的内容拆分开来
3）需要理解变化的来源，知道把不同行为者负责的代码放到不同的地方
判断是否满足单一职责的一些具体的方法：
1)类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性
2)类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想
3)私有方法过多，就要考虑能否将其独立到新的类中，设置为public，供更多的类使用，提高代码的复用性
4)比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰
5)类中大量的方法都是集中操作类中的某几个属性，就可以考虑将这几个属性和对应的方法拆分出来
此文章为3月Day1学习笔记，内容来源于极客时间《设计模式之美》
