💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
## 连载:面向对象葵花宝典:思想、技巧与实践(30) - SRP原则 前面详细阐述了“高内聚低耦合”的总体设计原则,但如何让设计满足这个原则,并不是一件简单的事情,幸好各位前辈和大牛已经帮我们归纳总结出来了,这就是“设计原则”和“设计模式”。毫不夸张的说,**只要你吃透这些原则和模式并熟练应用,就能够做出很好的设计**。 ================================================================== **【SRP原则详解】** SRP,single responsibility principle,中文翻译为“单一职责原则”!   这是面向对象类设计的第一个原则,也是看起来最简单的一个原则,但这实际上远远没有那么简单,很多人都不一定真正理解了!   我们随便找几个网上的解释,看看各位大师或者经典网站是如何解释的: 百度百科([http://baike.baidu.com/view/1545205.htm](http://baike.baidu.com/view/1545205.htm)): 一个类应该有且仅有一个职责。关于职责的含意,面向对象大师Robert.C.Martin有一个著名的定义:所谓一个类的职责是指引起该类变化的原因,如果一个类具有一个以上的职责,那么就会有多个不同的原因引起该类变化,其实就是耦合了多个互不相关的职责,就会降低这个类的内聚性。 说句实话,虽然是面向对象大师Martin的解释,我还是看得不甚明白:引起类变化的原因太多了,例如: 给类加一个方法是变化吧? 给类加一个属性是变化吧? 类的函数增加一个参数是变化吧? 。。。。。。 引起这些变化的原因太多了,如果每个原因都是一个职责,那SRP原则简直就没法判断了! Wiki百科([http://en.wikipedia.org/wiki/Single_responsibility_principle](http://en.wikipedia.org/wiki/Single_responsibility_principle) )内容和百度百科基本一致,看起来百度百科像wiki百科的翻译:) Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. 除了这些标准的解释外,还有一种说法:SRP就是指每个类只做一件事! 这个解释更通俗易懂,也更加适合中国人理解。虽然比Martin大师的解释更清楚一些,但仔细想想,还是有个地方比较难以理解:什么叫做“一件事”?   比如说一个学生信息管理类,这个类有“添加学生信息”、“查询学生信息”、“修改学生信息”、“删除学生信息”,那么这是4件事情,还是一件事情呢?   看起来好像是4个事情,但稍有经验的朋友应该都知道,这4个事情绝大部分情况下都是一个类来实现的,而不是分成4个类!   所以关键的问题在于:什么是“一件事”?是每个功能一件事情么?    其实答案就在我们自己身上,因为只要我们工作,无时不刻的承担着一定的“职责”! 现在让我们抛开面向对象,抛开软件,抛开计算机,来看看我们自己的“职责”。   比如说,我是一个程序猿,我的职责应该是“写程序”,但写程序有很多事情,例如:编码,单元测试、系统测试,bug修复,开会,写文档。。。。。。 再比如说,我的BOSS是一个管理者,他的职责是“管理程序猿”,他也有很多工作,例如:制定计划,团队建设、开会、协调资源、写文档。。。。。。 又比如说,我是一个快递员,也有很多工作:分包、快递、收款、开会。。。。。。   这些职责其实都不是我们自己定义的,而是公司或者部门或者组织给我们安排工作的时候定义的,也就是说:“职责”是站在他人的角度来定义的,而不是自己定义的,也许你想把自己定义成CEO,但你的老板会真的让你当CEO么?   经过对我们自己的职责的分析,我们可以得出两个关于职责的重要结论: 1) 职责是站在他人的角度来定义的 2) 职责不是一件事,而是很多事情,但这些事情都是和职责紧密相关的   对应到面向对象设计领域,我们可以说一个类的职责应该如下定义: 1) 类的职责是站在其它类的角度来定义的; 2) 类的职责包含多个相关功能;   因此,SRP可以翻译成“**一个类只负责一组相关的事情**”,对应到代码中就是:一个类有多个方法,这些方法是相关的。   当然,如果你再让我解释什么是“相关”,那我只能吐血了:)   有了这个定义,我们再来看“学生信息管理类”,很明显,学生管理类具有的4个功能都是和“管理”相关的,按照SRP原则,应该只设计一个“学生信息管理类”就可以了。   **【SRP原则范围】** 但现实世界往往比理想要复杂,一个最典型的例子就是“办公一体机”。 根据SRP原则,打印机可以设计成一个类,复印机也可以设计成一个类,扫描仪也可以设计成一个类,传真机还是可以设计成一个类,但偏偏就是出了个“办公一体机”,这个机器集成了“打印、复印、扫描、传真”4个职责! 如果我们要设计一个“办公一体机”的类,怎么也不可能设计出一个符合SRP原则的“办公一体机”的类来!   怎么办?是SRP不正确么,还是我们永远都不要设计“办公一体机”这样的类?   其实SRP也没有错,“办公一体机”也应该设计,但:不要用SRP来约束“办公一体机”这样的类! 也就是说,SRP其实是有适应范围的,SRP只适合那些基础类,而不适合基于基础类构建复杂的聚合类。   在“办公一体机“的样例中,“打印机”、“复印机”、“扫描仪”、“传真机”都是基础类,每个类都承担一个职责,而办公一体机是“聚合类”,同时集成了4种功能!   细心的朋友可能会继续问道:SRP不能应用于聚合类,那么如何保证聚合类的设计质量呢? 这个问题的答案在GoF的《设计模式》一书中有详细的答案,即:优先使用对象组合,而不是类继承。详细内容请参考后续“设计模式”部分的内容