[设计模式]面向对象设计原则之单一职责原则

单一职责原则的由来

初学者在编程的时候可能一开始会有这样的经历，使用一个类来实现很多的功能，新添加的甚至不相关的功能都放在一个类里来实现，煮成了一锅大杂烩，往往使得某个类包罗万象，无所不能。可能刚开始实现功能比较简单，这样做不会引发什么特别大的问题。但是随着项目复杂度的提升，各种不相关的实现代码耦合在一起，一旦有功能的更改或增删，修改的代码很可能会导致其他功能的正常运行。这种编程方式显然是不可取的，也就是违背了所谓的单一职责原则。

什么是单一职责原则？

    就是不要让你的类太“累”。简单的说就是一个类只负责一项职责！（够简单吧）

对于职责的理解

其实就算你没有学过单一职责原则，我想你的老师在平常的讲课中，你看到的任何一本有关代码的书籍中，都有提到类似的说法。因为谁都不希望在代码开发中修改一个地方会引发另外一个地方出现问题，也就是前任踩了无数个坑之后，大家都不爽了约好了把这个坑公布出来告诉后来者，这里有个坑啊！然后再告诉你怎样避免这个坑。那么我想你肯定不会再去看着天往里直接跳了。

但是！（这样大喘气挺难受的，不过真的要注意）但是！ 并不是说我们去写任何程序都是一个类真的就只负责一项职责。（明明你前端不忙，为什么不可以把那一点点图片ps了，还得非要再请一个人）

那不是扯犊子吗？我真的没有扯犊子！我们必须要意识到，一味的遵守单一职责原则，不停的分拆类所付出的开销是很大的。这时候就涉及到平衡的问题，平衡单一职责原则与修改造成的开销。我的观点是如果一个方法逻辑不复杂的情况下，可以修改方法实现，否则要拆分为两个方法，遵循方法级别的单一职责原则；如果一个类方法不多的情况下，可以只增加方法，而不用分拆为多个类，否则要拆分为多个类，遵循类级别的单一职责原则。（真当你的类分成了一个个功能，其实对程序的管理也会变的有点难以掌控，毕竟太大了！）

遵循单一职责原则的优点

• 降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。
• 提高了代码的可读性。一个类简单了，可读性自然就提高了。
• 提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。
• 变更引起的风险变低了。单一职责最大的优点就是修改一个功能，对其他功能的影响显著降低。