单一职责原则

什么是单一职责原则？

There should never be more than one reason for a class to change.

应该有且仅有一个原因引起类的变更。

我们假设：

有一个问题 P，P 可以被分解为 D 和 E 两个粒度比 P 小一些的问题解决，而 D 和 E 又可以分别被分解为 A、B 和 C、D 两个不需要或者实际不可再分的粒度比 D、E 更小的问题，如图：

理想情况下会是金字塔的结构，任何一个需求都可以被分解为不可再分的粒度的函数实现。

为了不重复造轮子，这些最小粒度的函数又可以和同粒度的函数结合产生一个新的函数供上层调用，这样一层一层的构成会是耦合程度最理想、应用最灵活的代码。

但实际情况是：如果真的严格遵守、实践 SRP，一定会得到一个类爆炸的结果，实际应用中因为底层函数太多，开发者不会记得住，最后还是难以避免冗余的函数实现出现。

所以实践中是：接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。