设计模式六大设计原则（一）：单一职责原则

什么是单一职责原则

单一职责原则的原话是：

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

翻译过来就是应该有且仅有一个原因引起类的变更。

要知道，我们的方法、接口、类都是基于职责设计的，只是粒度不同，单一职责原则，强调的是我们的方法、接口、类不应该包含太多的职责。

为什么要实现单一职责原则

1. 最重要的一点，是因为需要尽量控制职责变化造成不可控的大范围的变化。降低变更风险，如果一个方法包含的职责过多，那么只要其中一个职责变化，我们就需要修改方法，但是修改方法原则上来说我们需要确保所有调用者的期望返回不会受影响。可是如果方法职责过多，那么基于需求变动，方法修改的频率也会增多，同时另一方面方法影响的调用者也比实现了单一职责的方法范围大，这回对我们维护带来很大的麻烦。同理，接口、类包含的职责过多，弊端也是如此。
2. 增强了可读性。因为方法、接口、类都是对代码的封装，对于使用者来说不需要了解其内部实现。单一职责使得我们看到这个方法、接口、类的引用时我们就明确的知道了使用者的意图，想使用什么职责而不至于深入去看内部实现。

实践中的痛点

1. 实践中最最重要的痛点是我不知道怎么划分这个职责啊，方法的职责粒度该是什么，接口的职责粒度该是什么，类的职责粒度该是什么。
2. 职责粒度划分的越细，编写时类和代码量都会增多。

关于如何划分职责粒度的建议

基于需求变动的预判考虑

基于实际需求的变化可能性程度自己判断，职责划分的粒度取决于需求的粒度，如果一个职责预判会根据需求经常发生改变，那么这个职责应该被独立出来。

按方法、接口、类粒度从小到大进行控制

其次对于方法、接口、类实现单一职责的原则，对职责划分粒度排序应该是方法>接口>类。方法粒度最小可以理解，因为方法属于接口或类，接口排在类前面是因为我们在实际编程当中是面向接口编程，方法的入参出参都是接口，只有在方法内部实现的时候是采用实例实现接口。所以接口粒度要求比类要严格一些（两个拥有各自职责的接口可以由一个类来实现）。

基于可读性考虑

考虑是否职责的进一步划分会使得代码可读性提高，封装之后，只看外部引用，不看内部细节，是否能一目了然。

转载于:https://my.oschina.net/u/4101481/blog/3032748