五一假期结束了, 今天继续读一下第三章:函数的相关内容, 其实函数的相关内容设计到的东西很多, 想把一个函数写好也是很难的; 还是按照之前的样子, 先总结一下本章内容, 然后聊一下相关的话题

内容总结

• 函数应该尽量小

  ​ 在从业生涯中我见过最长的一个函数是几千行, 那简直就是程序员的噩梦, 所有的逻辑耦合在一起, 想要搞明白这个函数都干了什么还真要费一番功夫。更有甚者, 连原作者有时候都得重新梳理一下。造成这种情况的原因就是对函数没有整体的规划, 对于函数我们不能像写作文那样, 直抒胸臆, 挥毫泼墨; 要明确抽象的层次, 比如造飞机这个函数来说, 应该把机头啊, 机翼啊这些的创建放在第一层函数内, 细节下沉, 逐步细化, 这样才对。造成这种的原因我认为和软件设计思想有关, 没有整体的规划与设计, 上来就是一梭子, 想到哪写到哪肯定会有这样的问题啊!

  ​ 关于函数到底多小算小, 书中作者说的是嵌套的层次不能大于1, 其实只要按照上面的思想进行设计, 具体的量化标准, 我感觉没那么重要;

• 函数参数尽量少

  ​ 参数多了会让人产生混乱, 很难对应起来, 复杂度就上来了。 尽量减少参数, 作者的说法是控制在1-2个参数, 尽量不写3个参数的函数; 如果参数太多可以封装成一个对象, 然后传入。

• 函数命名尽量详尽

  ​ 这一点和上一章的命名相关的东西能呼应上, 就不做过多补充了

上面是内容总结, 书中其实有好多条目性的内容, 我只是进行了归纳性的总结, 当然可能有总结不到位的地方。但我实在不想对书中的内容进行复述, 那样违背了写博文的初衷。大家觉得哪里理解的有问题, 可以在评论区沟通交流!

下面我们还是聊几个相关的话题

几个相关的原则

• 单一职责原则

  单一职责原则想必大家并不陌生吧, 甚至有的同学都背的滚瓜烂熟了, 但是这个原则实践起来并不容易; 我之前的一篇介绍设计模式的文章中也提到过。

  而函数要实现尽可能小离不开这个原则, 换句话说, 如果函数违背了这个原则, 你有义务把他拆开。

• 开闭原则

  开闭原则大家也不陌生, 这个原则最终也是服务于让函数尽可能小, 关于这个原则我也不过多展开了, 有兴趣的可以去看看我之前的讲设计模式的那篇文章

• DRY原则

  写代码的时候应该经常会遇到这个问题, 就是相近的代码逻辑会出现在不同的函数中, 改动就得改动多处, 这就违反了DRY原则, 当然也就导致了函数会变长

• CQRS原则

  命令查询分离原则, 这个原则意思是修改和查询要分开, 乍一看大家肯定觉得, 谁写的函数不是这样的? 但确实有一些这样的反例, 例如作者书中提到的, 修改某个键的值, 如果修改成功就返回true, 如果不存在就返回false, 大家仔细体会体会这样的是不是存在问题。当然这个CQRS原则在宏观上还指导着架构设计, 如读写分离本身也是这个原则的衍生物。

if/else和switch语句的优化

一个函数中如果充斥这大量的if/else或者switch语句, 想短也短不了啊。那么if/else和swith语句这种应该怎么优化呢? 最通用的方案是工厂模式+策略模式, 当然怎么实现还是有很多技巧的, 具体的就不过多展开了。这里提一下, 如果因为使用工厂模式导致类爆炸的情况可以使用装饰者模式或适配器模式进行优化。

模板模式

优化函数, 模板模式也是常用的方法。准确地说, 模版模式就是抽象层次的封装, 与本章中函数尽量小的优化思路, 非常吻合; 模版模式的使用也比较简单, 就不展开了。

责任链模式

优化函数, 责任链模式也很有用, 在一个函数内, 本身逻辑就是顺序的, 既然是顺序的就有前后相关性, 这本身就能串成一条链; 如果在代码中还有一些if/else的判断啊, 那么就可以动态配置责任链的节点来实现。

源码中经常出现的Context类

之前我最早看源码的时候, 会经常看到xxxContext类, 最让我理解不了的是什么是上下文, 这个名字听着怎么这么抽象呢? 好了, 具象一点, 函数的上下文就是函数执行过程中用到的变量(包括参数和成员变量), 而依据函数参数尽量少来说, 如果参数太多可以都封装到一个类中, 这个类就可以命名为xxxContext。