金融网站建设案例,怎么在微信创建公众号,wordpress伪静态 iis,软件技术主要学什么就业方向单一职责原则
类的设计原则之单一职责原则#xff0c;是最常用的类的设计的原则之一。
百度百科#xff1a;就一个类而言#xff0c;应该仅有一个引起它变化的原因。应该只有一个职责。
通俗的讲就是#xff1a;一个类只做一件事
这个解释更通俗易懂#xff0c;也更符…单一职责原则
类的设计原则之单一职责原则是最常用的类的设计的原则之一。
百度百科就一个类而言应该仅有一个引起它变化的原因。应该只有一个职责。
通俗的讲就是一个类只做一件事
这个解释更通俗易懂也更符合中国人的理解。但是仔细想想还是有几个地方比较难理解
什么叫做 “一件事”
举个例子
比如有一个学生管理类这个类有 添加学生信息 , 修改学生信息 查询学生信息 删除学生信息
问题来了 这是 4 件事 还是 1 件事
看起来好像是 4 件事 但是稍有经验的人都知道这 4 件事都是由一个类来实现的而不是设计 4 个类
所以问题的关键在于什么是 “一件事” 是每个功能一件事吗
其实答案就在我们自己身上 因为只要我们工作就无时无刻的在承担着一定的职责
现在抛开面向对象抛开软件抛开计算机来看看我们自己的职责
比如我是一个程序员我的职责是写程序 但 写程序 有很多事情例如 编码单元测试系统测试bug修复开会写文档 等 比如我的老板是一个管理者他的职责是 管理程序员 ,他也有很多工作例如 制订计划 , 团队建设 开会 ,协调 绩效考评 等 比如我是一个快递员我的职责是送快递但是我也有很多事要做例如 分包 , 快递 ,收款 , 开会 等 这些职责都不是我们自己定义的而是公司或者部门或者组织给我们安排工作的时候定义的。
也就是说职责 是站在他人的角度上定义的而不是我们自己定义的。
经过我们对职责 定义的分析我们可以得出 2 个关于职责的重要结论
职责是站在他人的角度上定义的 职责不是一件事而是很多事但这些事都是和职责紧密结合的。
对应到面向对象设计领域我们可以说一个类的职责应该如下定义
类的职责是站在其它类的角度来定义的 类的职责包含多个相关功能 因此SRP 可以翻译为 一个类只负责一组相关的事 对应到代码中就是一个类有多个方法这些方法是相关的
有了这个定义我们再来看看学生信息管理类 很明显它具有的 4 个功能都是和 管理 相关的按照 SRP 应该只设计一个学生信息管理类就可以了。
SRP 的应用范围
但是现实世界往往比理想更复杂一个最典型的例子就是 办公一体化
根据 SRP 打印机可以设计成一个类复印机可以设计成一个类扫描仪可以设计成一个类传真机也可以设计成一个类
但偏偏就出了一个 办公一体化 这个机器集成了 打印 复印 扫描 , 传真 4 个职责
如果我们设计一个 办公一体化 的类怎么也不可能设计出一个符合 SRP 的 办公一体化的类
怎么办 是 SRP 不正确 还是我们永远都不要设计一个 办公一体化 的类
其实 SRP 没有错 办公一体化 也应该设计 但是不要用 SRP 原则来约束 办公一体化 这样的类
也就是说 SRP 其实是有适用范围的 SRP 只适合那些基础类而不适合基于基础类构建复杂类的聚合类
在办公一体化 的样例中 打印机 ,复印机 ,扫描仪 传真机 都是基础类每个类都承担一个职责
而 办公一体化 是一个聚合类 同时集成了4种功能
细心的你可能发现了SRP不能应用于聚合类 那么如何保证聚合类的设计质量呢
换句话说遇到这样的情况如何设计这样的聚合类呢
这个问题在 GoF 的 《设计模式》 一书中有详细的答案即优先使用对象组合 而不是类继承。
类的单一原则就到这里了现小结一下
类的单一原则(SRP)一个类只负责一组相关的事 对应到代码中就是一个类有多个方法这些方法是相关的 职责是站在他人的角度上定义的 类的职责包含多个相关功能 SRP 只适合那些基础类而不适合基于基础类构建复杂类的聚合类 对于复杂的聚合类优先使用组合 而不是继承
