单一职责原则，顾名思义，就是要让一个类或者一个接口只实现单一的功能。但是这个功能的单一性的定义要根据不同的情况做不同的考虑，一个类或者接口如果包含太多的很可能变化的功能，那么是绝对不满足单一职责原则的。

如果是这样一个类的话，会有什么缺点或者说是漏洞呢？第一，定义的类或者接口会变得很复杂；第二，因为复杂所以可读性会变得很低；第三因为可读性很低，后期会很难维护，也就是可维护性很低；第四，在出现一种变更时，很有可能出现牵一发而动全身的情况，引起别的部分也跟着变化，这样的设计会存在很高的风险。

但是反过来，我们定义很多类或者接口，一个类里面只有简单的一两个方法，这样满足单一职责原则了吗？表面上看是满足了SRP，但是其实这种设计也是不符合SRP的初衷的。因为有些可能出现的变化在对应实际情况看来，很可能两年，三年内不会有变化，那么这种变化单独提出来是没有多大意义的，反而耗费更多资源，也使得系统结构变得异常复杂。这样做得不偿失！如果仅仅对于Robert C. Martin的“Each class should have one and only one re@H_301_34@ason to change”这句话去死钻的话，只能说明你是没有理解大师的思维。我们要用一种中庸的态度去看待这些变化，这些变化一定要是在业务现实中会有而且是短期内会有的实际大变化的变化。