重复性管理——从泛值到泛型以及泛函(下)
博客专区 > 国栋 的博客 > 博客详情
重复性管理——从泛值到泛型以及泛函(下)
国栋 发表于6个月前
重复性管理——从泛值到泛型以及泛函(下)
  • 发表于 6个月前
  • 阅读 291
  • 收藏 14
  • 点赞 0
  • 评论 10

在前面我们谈论了重复性管理上的一些具体做法,重点探讨了泛型范式泛函范式在解决重复性问题上的应用。因为前面的篇幅有很多被具体的代码例子占据了,所以留到现在这篇做一个归纳总结。

与数学的渊源

应该说,编程与数学还是颇有渊源的,或者说它们之间有很多相通的地方。数学的一个突出特点,那就是数学家总是在不断寻求更加一般化的表述,更为抽象的表达。我们来看一个具体的例子。

数学上有所谓的勾股数,最知名的就是我们所熟知的“勾三股四玄五”了。具体而言就是 3^2 + 4^2 = 5^2.

注:3^2 表示 3 的 2 次方(平方),因为上标较为麻烦,其余类似。

类似的正整数组合还有比如:5^2 + 12^2 = 13^2.

显然,我们都知道这些都是勾股定理的一些正整数特例而已,数学家们肯定不会只满足与此,很早他们就发现了所有的直角三角形都满足一个一般化的表达如下:

a^2 + b^2 = c^2.

这就是所谓的“勾股定理”了。

在西方,叫“毕达哥拉斯定理”(Pythagorean theorem)

那么,是否到这里,事情就结束了呢?如果你还记得曾经学过的数学,那么你应该还记得有个东西叫“余弦定理(law of cosines)”,具体如下:

image

当角度 γ 为 90 度时,因为 cos(90) = 0,这样“余弦定理”就简化成了所谓的“勾股定理”。所以,余弦定理是比勾股定理更加一般化的表述。

3,4,5 和 5,12,13 这些勾股数是勾股定理的特例,而勾股定理本身又是余弦定理的一个特例。

从勾三股四玄五到勾股定理再到余弦定理,从特殊到一般,从一般到更一般,显然,数学家从未停止他们抽象的脚步,总是在追寻更加一般化的定理,更加普适的定律。

事实上,这个平面上的余弦定理还可以进一步推广到立体的“四面体(tetrahedron)”上的余弦定理:

image

这个就比较深奥,比较抽象了,恐怕知道的人也不多,但数学家们是不会停止的!这个可谓是更加一般化的表述了。

反之,平面上的余弦定理可以视作为它的一个特例。

类似的例子还有很多,事实上你在中学里所学的好多定理都还可以进一步推广,不过因为在形式上也越来越抽象,很多已经超出了我们普通人的理解能力,这里也不再去挖掘那些例子了。

所谓的“泛”

现在,我们来看所谓的“泛”,前面的篇章中也一再说了,就是一个从特殊到一般的过程:

image

是一个从具体到抽象的过程:

image

函数已经是一种抽象,我们还不满足,我们还要追求更高阶的抽象:

image

还是那句话,从特殊到一般,从一般到更一般!无论是值的硬编码、类型的硬编码,还是行为的硬编码,能够被泛化的,我们都将其一一参数化,一般化。

在这一过程中,我们消除了重复,得到了极为抽象的代码,这些对值没有依赖,对类型也没有依赖,对具体行为也没有耦合的代码具有极强的普适性。依靠这些手段,我们不但消除了眼下的重复,甚至也消除了未来的重复。

当你写的代码越来越多,当你思考得越来越深,你一定对这一点体会越来越深。或许我们还不能将它清晰的表述出来,但我相信我们一定会逐渐地感受到,用陶潜的一句诗来结尾,可谓是:此中有真意,欲辨已忘言!

image

注:图片来自互联网。附上原诗:

饮酒(其五)—— 陶渊明

结庐在人境,而无车马喧。
问君何能尔?心远地自偏。
采菊东篱下,悠然见南山。
山气日夕佳,飞鸟相与还。
此中有真意,欲辨已忘言。

共有 人打赏支持
国栋
粉丝 352
博文 78
码字总数 154046
评论 (10)
charles_wang
好文,要顶.
国栋

引用来自“charles_wang”的评论

好文,要顶.

回复@charles_wang : :smiley:
liuqiangchengdu
这一篇文章从总结升华到哲学化,然后诗化。能写下这样的好文,给个赞。
国栋

引用来自“liuqiangchengdu”的评论

这一篇文章从总结升华到哲学化,然后诗化。能写下这样的好文,给个赞。

回复@liuqiangchengdu : :blush:过奖了~
seal_90
写个文章也真是不易啊 果断各种知识都需要
飞天奔月
鼓掌, 上中下 三篇文章,我都仔细拜读了, 学到做, 做到说, 说到写, 每个阶段都浓缩在上面三个文章里面了, 不管是程序员, 架构师,还是"数学家", 都会有很大的感悟和受益
国栋

引用来自“seal_90”的评论

写个文章也真是不易啊 果断各种知识都需要
:smile:
国栋

引用来自“飞天奔月”的评论

鼓掌, 上中下 三篇文章,我都仔细拜读了, 学到做, 做到说, 说到写, 每个阶段都浓缩在上面三个文章里面了, 不管是程序员, 架构师,还是"数学家", 都会有很大的感悟和受益
:smile:谢谢
木木小胖
感觉有时候抽象也不是有百利而无一害的,过度抽象也会带来重复
比如如果将列表求和再次抽象,变成列表求X,传入两个参数,函数用第一个参数处理每个列表项,收集返回值传入第二个参数里,这样可以实现列表求乘积,但是如果只需要求和,每次传入都必须传入一个求和函数
如果还有元组求X,集合求X,每次传入还得传入一个foreach()【或者对于一些不满足交换性的运算,得先进行某些预处理才能正确遍历】
那么代码可能会变成这样子
int sqSum = sum([1..100], (x,y)->x+y, x->x*x);

【可能有一些语法上的错误【我没学过Java】,但是只要不妨碍阅读就好】

当然应该还可以进一步泛化,但是这样每次调用都必须传入一些重复参数
所以,有时候针对场景进行的特化是有必要的(..?)

【总感觉我理解错文意了】
国栋

引用来自“木木小胖”的评论

感觉有时候抽象也不是有百利而无一害的,过度抽象也会带来重复
比如如果将列表求和再次抽象,变成列表求X,传入两个参数,函数用第一个参数处理每个列表项,收集返回值传入第二个参数里,这样可以实现列表求乘积,但是如果只需要求和,每次传入都必须传入一个求和函数
如果还有元组求X,集合求X,每次传入还得传入一个foreach()【或者对于一些不满足交换性的运算,得先进行某些预处理才能正确遍历】
那么代码可能会变成这样子
int sqSum = sum([1..100], (x,y)->x+y, x->x*x);

【可能有一些语法上的错误【我没学过Java】,但是只要不妨碍阅读就好】

当然应该还可以进一步泛化,但是这样每次调用都必须传入一些重复参数
所以,有时候针对场景进行的特化是有必要的(..?)

【总感觉我理解错文意了】
重要的是降低复杂性,如果你引入了抽象没有降低复杂性反而是增加了复杂性,那就不值得引入。
文中为了叙述方便及读者理解方便都是举的比较简单的例子,重点在于说明如何去做抽象,而不是谈论抽象是否合理或过度的问题。
×
国栋
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: