锁定老帖子 主题:论面向组合子程序设计方法 之 微步毂纹生
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2005-08-07
这个文章是关于怎么样以群众喜闻乐见的方式在java开发中应用上帝他老人家的方法学(我猜的)—— 面向组合子。 第一章 创世纪 http://forum.iteye.com/blog.php?userid=6423 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2005-08-07
CO研究过,经过和OO的反复对比之后,结论是OO并不排斥CO,换句话说CO本来就是OO的天然构成部分,只是经常被人忽视而已。
|
|
返回顶楼 | |
发表时间:2005-08-07
最终还是ajoo同志比较靠谱。
一上来就云里舞里号称颠覆OO的,最终写出程序来跟C++和JAVA其实没有本质区别;倒是ajoo这形而下的,清清楚楚写出来的程序就跟JAVA是不一样的东西。所以老话说得好,少谈点主义多谈点问题。 |
|
返回顶楼 | |
发表时间:2005-08-07
ajoo 写道 东施效颦,学学老庄,搞个连载。
有人说,上帝是用OO设计的世界,可要我是上帝,我宁可用CO。 设计几个简单的基本粒子,几个简单的相互作用力,然后让这些东西自己组合,随意发展,不是比事必躬亲,先想透彻了自己想让世界是什么样子,然后一张一张图纸地具体设计,一个一个人地造, “撒旦,你去干坏事,往死了整这帮贱人!” “天使,你去干好事,打个巴掌再给他们点甜枣吃。” “儿子,你下去混混,看着帮贱人敢不敢钉死你!” 来的容易美妙? 上帝本来就是用CO来构造世界,剩下的就是是掷骰子。 我们不是上帝,没有办法揣测上帝掷出的骰子下一步会滚出什么数字,所以只好用OO去抽象,隐藏所有细节,只见其表不见其里,只有这样才能将复杂度控制在可以承受的范围之内。不好意思,现在轮到我来说你不懂OO了。 |
|
返回顶楼 | |
发表时间:2005-08-07
age0 写道 ajoo 写道 东施效颦,学学老庄,搞个连载。
有人说,上帝是用OO设计的世界,可要我是上帝,我宁可用CO。 设计几个简单的基本粒子,几个简单的相互作用力,然后让这些东西自己组合,随意发展,不是比事必躬亲,先想透彻了自己想让世界是什么样子,然后一张一张图纸地具体设计,一个一个人地造, “撒旦,你去干坏事,往死了整这帮贱人!” “天使,你去干好事,打个巴掌再给他们点甜枣吃。” “儿子,你下去混混,看着帮贱人敢不敢钉死你!” 来的容易美妙? 上帝本来就是用CO来构造世界,剩下的就是是掷骰子。 我们不是上帝,没有办法揣测上帝掷出的骰子下一步会滚出什么数字,所以只好用OO去抽象,隐藏所有细节,只见其表不见其里,只有这样才能将复杂度控制在可以承受的范围之内。不好意思,现在轮到我来说你不懂OO了。 这话只能说明你不懂CO。 CO就不能抽象?就不能隐藏细节?哪儿跟哪儿啊? 你理解的CO可能还是传统的面向过程的方法吧? |
|
返回顶楼 | |
发表时间:2005-08-07
引用 OO的关键是需求。 所谓"refactor",不过也是强调需求,让你不要自作聪明地瞎假设需求而复杂化设计。时刻着眼于当前的需求。这样,一旦需求变更,所浪费的力气可以保证最小,而且,船小才好调头嘛。 如果需求分析的不好,一切就歇菜了,虽然因为一些比如ioc之类的设计方法能让你不至于推到重来,但是需求仍然是重中之重。 那些什么上下文没有,上来就说“怎么用OO来做一个人骑车呀?”,“是人.骑(车)呀?还是车.被骑(人)?”纯粹是没头没脑地瞎掰。 而CO的关键则是组合子和组合规则的设计。这些组合方法必须非常精巧,尽量正交。组合子的设计既要简单(越简单才越容易被组合),还要完整。 比如说,对整数这个组合子,我们有+-*等组合方法,这样只要有了0,1这两个组合子,我们就可以构造出整个整数世界。 可是,精巧的组合子设计也不是那么容易的。需要有一点点数学的感觉和严密的逻辑思维基础。 真是太赞同了! 没有上下文(需求)的OO是没有任何意义的。 |
|
返回顶楼 | |
发表时间:2005-08-07
没看到CO 和 OO有多大区别。
看了你对logging的一大堆需求分析,难道这不是对需求的透彻的分析?只不过CO似乎着重于某个方面,而OO有个系统整体需求的前提。 两者在设计一开始似乎考虑的着重点不大一样。 不过不管如何,具体过程上,他们应该差不多的。 组合子这个概念有必要说清楚它与对象的关系。 我也没看到分析得出组合子的过程与OO设计相比有何优越性? 这个过程我认为还是很复杂的。 |
|
返回顶楼 | |
发表时间:2005-08-07
firebody 写道 没看到CO 和 OO有多大区别。
看了你对logging的一大堆需求分析,难道这不是对需求的透彻的分析?只不过CO似乎着重于某个方面,而OO有个系统整体需求的前提。 两者在设计一开始似乎考虑的着重点不大一样。 不过不管如何,具体过程上,他们应该差不多的。 组合子这个概念有必要说清楚它与对象的关系。 我也没看到分析得出组合子的过程与OO设计相比有何优越性? 这个过程我认为还是很复杂的。 别急。老大,你不是没看过连载吧? |
|
返回顶楼 | |
发表时间:2005-08-07
ajoo 写道 firebody 写道 没看到CO 和 OO有多大区别。
看了你对logging的一大堆需求分析,难道这不是对需求的透彻的分析?只不过CO似乎着重于某个方面,而OO有个系统整体需求的前提。 两者在设计一开始似乎考虑的着重点不大一样。 不过不管如何,具体过程上,他们应该差不多的。 组合子这个概念有必要说清楚它与对象的关系。 我也没看到分析得出组合子的过程与OO设计相比有何优越性? 这个过程我认为还是很复杂的。 别急。老大,你不是没看过连载吧? 没看过。 什么连载? 我很有兴趣,说给我听听,我立即补课. |
|
返回顶楼 | |
发表时间:2005-08-07
看起来有点像构造公理系统的办法,不过,那样一来,需要证明这套组合子和组合规则形成的系统的一致性、可靠性和完备性。这个可能要有那么一点点数理逻辑和形式语义学的相对深入一点的背景知识。
|
|
返回顶楼 | |