本文主要是介绍代码整洁之道第3章-函数,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
五一假期结束了, 今天继续读一下第三章:函数的相关内容, 其实函数的相关内容设计到的东西很多, 想把一个函数写好也是很难的; 还是按照之前的样子, 先总结一下本章内容, 然后聊一下相关的话题
内容总结
-
函数应该尽量小
在从业生涯中我见过最长的一个函数是几千行, 那简直就是程序员的噩梦, 所有的逻辑耦合在一起, 想要搞明白这个函数都干了什么还真要费一番功夫。更有甚者, 连原作者有时候都得重新梳理一下。造成这种情况的原因就是对函数没有整体的规划, 对于函数我们不能像写作文那样, 直抒胸臆, 挥毫泼墨; 要明确抽象的层次, 比如
造飞机
这个函数来说, 应该把机头啊, 机翼啊这些的创建放在第一层函数内, 细节下沉, 逐步细化, 这样才对。造成这种的原因我认为和软件设计思想有关, 没有整体的规划与设计, 上来就是一梭子, 想到哪写到哪肯定会有这样的问题啊! 关于函数到底多小算小, 书中作者说的是嵌套的层次不能大于1, 其实只要按照上面的思想进行设计, 具体的量化标准, 我感觉没那么重要;
-
函数参数尽量少
参数多了会让人产生混乱, 很难对应起来, 复杂度就上来了。 尽量减少参数, 作者的说法是控制在1-2个参数, 尽量不写3个参数的函数; 如果参数太多可以封装成一个对象, 然后传入。
-
函数命名尽量详尽
这一点和上一章的命名相关的东西能呼应上, 就不做过多补充了
上面是内容总结, 书中其实有好多条目性的内容, 我只是进行了归纳性的总结, 当然可能有总结不到位的地方。但我实在不想对书中的内容进行复述, 那样违背了写博文的初衷。大家觉得哪里理解的有问题, 可以在评论区沟通交流!
下面我们还是聊几个相关的话题
几个相关的原则
-
单一职责原则
单一职责原则想必大家并不陌生吧, 甚至有的同学都背的滚瓜烂熟了, 但是这个原则实践起来并不容易; 我之前的一篇介绍设计模式的文章中也提到过。
而函数要实现
尽可能小
离不开这个原则, 换句话说, 如果函数违背了这个原则, 你有义务把他拆开。 -
开闭原则
开闭原则大家也不陌生, 这个原则最终也是服务于让函数
尽可能小
, 关于这个原则我也不过多展开了, 有兴趣的可以去看看我之前的讲设计模式的那篇文章 -
DRY原则
写代码的时候应该经常会遇到这个问题, 就是相近的代码逻辑会出现在不同的函数中, 改动就得改动多处, 这就违反了
DRY原则
, 当然也就导致了函数会变长 -
CQRS原则
命令查询分离原则, 这个原则意思是修改和查询要分开, 乍一看大家肯定觉得, 谁写的函数不是这样的? 但确实有一些这样的反例, 例如作者书中提到的,
修改某个键的值, 如果修改成功就返回true, 如果不存在就返回false
, 大家仔细体会体会这样的是不是存在问题。当然这个CQRS原则在宏观上还指导着架构设计, 如读写分离本身也是这个原则的衍生物。
if/else和switch语句的优化
一个函数中如果充斥这大量的if/else或者switch语句, 想短也短不了啊。那么if/else和swith语句这种应该怎么优化呢? 最通用的方案是工厂模式+策略模式
, 当然怎么实现还是有很多技巧的, 具体的就不过多展开了。这里提一下, 如果因为使用工厂模式导致类爆炸的情况可以使用装饰者模式
或适配器模式
进行优化。
模板模式
优化函数, 模板模式
也是常用的方法。准确地说, 模版模式就是抽象层次的封装, 与本章中函数尽量小
的优化思路, 非常吻合; 模版模式的使用也比较简单, 就不展开了。
责任链模式
优化函数, 责任链模式
也很有用, 在一个函数内, 本身逻辑就是顺序的, 既然是顺序的就有前后相关性, 这本身就能串成一条链; 如果在代码中还有一些if/else
的判断啊, 那么就可以动态配置责任链的节点来实现。
源码中经常出现的Context类
之前我最早看源码的时候, 会经常看到xxxContext
类, 最让我理解不了的是什么是上下文
, 这个名字听着怎么这么抽象呢? 好了, 具象一点, 函数的上下文就是函数执行过程中用到的变量(包括参数和成员变量), 而依据函数参数尽量少
来说, 如果参数太多可以都封装到一个类中, 这个类就可以命名为xxxContext
。
这篇关于代码整洁之道第3章-函数的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!