锁定老帖子 主题:论面向组合子程序设计方法 之 微步毂纹生
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-01-04
庄表伟 写道 规则引擎?
我倒确实很感兴趣这个方案和真正的rule engine的差别都在什么地方。rule engine天生就应该比这个方案强大,因为这个方案做起来太简单了。 |
|
返回顶楼 | |
发表时间:2006-01-04
zengjin8310 写道 ajoo 写道 比如前面age0给我们提出的“排他性”。三个规则,如果第一个成功了,就用第一个,否则顺序执行第二个,第三个,直到某一个规则成功.
我觉得真正把一个复杂的业务规则分析归结成排他的而且简化的一系列规则还是非常困难的,. 能不能提供一种方法论或者是你的感觉? 排他只是一种算法啊。还可以取最大,最小,求和,等等等等啊。 |
|
返回顶楼 | |
发表时间:2006-01-05
ajoo 写道 庄表伟 写道 规则引擎?
我倒确实很感兴趣这个方案和真正的rule engine的差别都在什么地方。rule engine天生就应该比这个方案强大,因为这个方案做起来太简单了。 我没有研究过规则引擎,但是直觉上这个需求应该是由规则引擎来做会更加灵活,建议研究一下。 还有就是“逻辑编程语言”(logical programming language),比如:Prolog。同样是出于直觉,我猜原子逻辑的概念,可能会比你的组合子更加灵活。 |
|
返回顶楼 | |
发表时间:2006-01-05
ajoo这个方案还是很不错的,无论是规则引擎还是Prolog,都离用户所关注的业务域太过遥远。真正的业务规则计算其实并不会太复杂,只是计算所需要的大量经过分析的信息都只能是由domain object提供,因此一个能够和业务系统无缝结合的规则系统远比无所不能的系统来得更有价值和意义。
|
|
返回顶楼 | |
发表时间:2006-01-05
age0 写道 ajoo这个方案还是很不错的,无论是规则引擎还是Prolog,都离用户所关注的业务域太过遥远。真正的业务规则计算其实并不会太复杂,只是计算所需要的大量经过分析的信息都只能是由domain object提供,因此一个能够和业务系统无缝结合的规则系统远比无所不能的系统来得更有价值和意义。
那我就建议你使用apache的functor了,它具有函数编程的组合意义,也具有OO的设计。 不过因为无法作很好的映射,那些Binary,Uniary接口看起来很是蹩脚,但是无论如何,它能够做起组合的工作,而且能够无缝结合你实际的领域模型。 基于functor最一个集成于现有领域模型的规则引擎,还是可以实现的。 |
|
返回顶楼 | |
发表时间:2006-01-05
ajoo 写道 庄表伟 写道 规则引擎?
我倒确实很感兴趣这个方案和真正的rule engine的差别都在什么地方。rule engine天生就应该比这个方案强大,因为这个方案做起来太简单了。 ajoo在这里的例子的确就是一个最simple的规则引擎。如果从规则引擎的角度衡量它,那么这个规则引擎没有推理引擎,也还没有抽象出规则语言,或者说它使用java class作为默认的规则语言,因此它的实施起来是很困难的。(规则语言一般是提供给客户或者实施人员使用的,让他们自己定制规则。很难想象让客户写java class)。 如果说从这个案例来理解co,我感觉从折扣策略业务系统->规则引擎业务系统这个分析过程就是co的过程。如果下一步老板还要求把程序员炒鱿鱼后还能自己改规则,不知道ajoo是不是就能co个规则语言出来了。 不知道这种理解对不对,还请各位大牛指点阿。 age0 写道 ajoo这个方案还是很不错的,无论是规则引擎还是Prolog,都离用户所关注的业务域太过遥远。真正的业务规则计算其实并不会太复杂,只是计算所需要的大量经过分析的信息都只能是由domain object提供,因此一个能够和业务系统无缝结合的规则系统远比无所不能的系统来得更有价值和意义。
恰恰相反,我觉得规则引擎通常都能和业务系统结合的很好,可以直接从RuleContext中获得domain object(参考JSR-94),只是需要客户掌握规则语言。不过大部分规则语言的语法都模仿自然语言,所以很好掌握。 不过就这个例子来说,我觉得还是应该直接采用规则引擎比较好,能够拿来的,干嘛要自己开发呢? |
|
返回顶楼 | |
发表时间:2006-01-05
夏日的猫 写道 ajoo 写道 庄表伟 写道 规则引擎?
我倒确实很感兴趣这个方案和真正的rule engine的差别都在什么地方。rule engine天生就应该比这个方案强大,因为这个方案做起来太简单了。 ajoo在这里的例子的确就是一个最simple的规则引擎。如果从规则引擎的角度衡量它,那么这个规则引擎没有推理引擎,也还没有抽象出规则语言,或者说它使用java class作为默认的规则语言,因此它的实施起来是很困难的。(规则语言一般是提供给客户或者实施人员使用的,让他们自己定制规则。很难想象让客户写java class)。 规则语言是不需要“抽象”的。:-) 只要在外面包一层脚本或者xml外壳就可以了。 实际上,没有api而只有“抽象的规则语言”的系统设计上不能说蹩脚,但是绝对谈不上优雅。而有了api,外面包裹规则语言则是相对简单的事了。 至于没有推理引擎。这正是我非常感兴趣了。从age0的这个例子来看,我们似乎用不到推理引擎这么高级的东西。那么可不可以说,在专业的rule engine和java硬编码之间,还是有那么一定的空间给co这种简易规则引擎的呢? 夏日的猫 写道 如果说从这个案例来理解co,我感觉从折扣策略业务系统->规则引擎业务系统这个分析过程就是co的过程。如果下一步老板还要求把程序员炒鱿鱼后还能自己改规则,不知道ajoo是不是就能co个规则语言出来了。 不知道这种理解对不对,还请各位大牛指点阿。 其实,我用jaskell写了一个规则语言出来的。当然,试图让非程序员写规则还是有点问题。(不过,我看drools的例子,似乎不懂编程的人也玩不转阿) 夏日的猫 写道 age0 写道 ajoo这个方案还是很不错的,无论是规则引擎还是Prolog,都离用户所关注的业务域太过遥远。真正的业务规则计算其实并不会太复杂,只是计算所需要的大量经过分析的信息都只能是由domain object提供,因此一个能够和业务系统无缝结合的规则系统远比无所不能的系统来得更有价值和意义。
恰恰相反,我觉得规则引擎通常都能和业务系统结合的很好,可以直接从RuleContext中获得domain object(参考JSR-94),只是需要客户掌握规则语言。不过大部分规则语言的语法都模仿自然语言,所以很好掌握。 不过就这个例子来说,我觉得还是应该直接采用规则引擎比较好,能够拿来的,干嘛要自己开发呢? 这是我另一个非常感兴趣的问题。对一些要求不那么复杂的场景,采用一个规则引擎有没有所谓“太重了”的顾虑呢?具体应对age0提出的这个问题,用规则引擎给出的方案是否足够贴近问题域呢?谁能给举个例子? |
|
返回顶楼 | |
发表时间:2006-01-05
firebody 写道 age0 写道 ajoo这个方案还是很不错的,无论是规则引擎还是Prolog,都离用户所关注的业务域太过遥远。真正的业务规则计算其实并不会太复杂,只是计算所需要的大量经过分析的信息都只能是由domain object提供,因此一个能够和业务系统无缝结合的规则系统远比无所不能的系统来得更有价值和意义。
那我就建议你使用apache的functor了,它具有函数编程的组合意义,也具有OO的设计。 不过因为无法作很好的映射,那些Binary,Uniary接口看起来很是蹩脚,但是无论如何,它能够做起组合的工作,而且能够无缝结合你实际的领域模型。 基于functor最一个集成于现有领域模型的规则引擎,还是可以实现的。 对不起,我感觉你有点想当然了。 如果用co作规则引擎是100步的话,apache functor的东西连10步都不到。基本上,apache的东西和co制作的规则引擎几乎是正交的关系。拿functor自然不能说不能做规则引擎,就象我拿c#, java,ruby, python都能做一样。但是functor这个库里面对规则引擎这种高阶逻辑提供的有价值的支持和帮助几乎等于0。它提供的那些“组合”和对规则的“组合”根本是不同的。就象我的jaskell虽然提供的函数组合,但是我还是要在java里面给出对Rule的组合子,这是两件互相不能代替的事情。 我不知道你从哪里得到的这个“基于functor做规则引擎”的想法的。费解。 |
|
返回顶楼 | |
发表时间:2006-01-05
ajoo 写道 其实,我用jaskell写了一个规则语言出来的。(不过,我看drools的例子,似乎不懂编程的人也玩不转阿) jaskell我看了一下,更像是bsh之类的脚本语言,不大像是规则语言啊。 ajoo 写道 不过,我看drools的例子,似乎不懂编程的人也玩不转阿 那个当然要培训了。不过想对于wfmc和其它script语言来说,我觉得已经是很简单的东西了。 ajoo 写道 夏日的猫 写道 不过就这个例子来说,我觉得还是应该直接采用规则引擎比较好,能够拿来的,干嘛要自己开发呢? 这是我另一个非常感兴趣的问题。对一些要求不那么复杂的场景,采用一个规则引擎有没有所谓“太重了”的顾虑呢?具体应对age0提出的这个问题,用规则引擎给出的方案是否足够贴近问题域呢?谁能给举个例子? 这个我回头贴出来,呵呵 不过单从灵活性和重用性来讲,只要需求存在不确定,而且对性能要求不是极端高的地方,我更倾向使用“重量级”的东西。比如只要i做简单的控制台分级日志输出的时候,我也会用log4j而不是MyLog——天知道什么时候要输入到日志文件?只要业务流程步骤稍微多一点的时候,我都会用osworkflow——不然以后流程变化了怎么办?只要可能存在不确定代码的时候,我都会用脚本语言。虽然好像是大炮打蚊子,不过既然大炮和炮弹都是免费的,哪又何妨呢? 好像有点离题了,哈哈 |
|
返回顶楼 | |
发表时间:2006-01-05
ajoo 写道 firebody 写道 age0 写道 ajoo这个方案还是很不错的,无论是规则引擎还是Prolog,都离用户所关注的业务域太过遥远。真正的业务规则计算其实并不会太复杂,只是计算所需要的大量经过分析的信息都只能是由domain object提供,因此一个能够和业务系统无缝结合的规则系统远比无所不能的系统来得更有价值和意义。
那我就建议你使用apache的functor了,它具有函数编程的组合意义,也具有OO的设计。 不过因为无法作很好的映射,那些Binary,Uniary接口看起来很是蹩脚,但是无论如何,它能够做起组合的工作,而且能够无缝结合你实际的领域模型。 基于functor最一个集成于现有领域模型的规则引擎,还是可以实现的。 对不起,我感觉你有点想当然了。 如果用co作规则引擎是100步的话,apache functor的东西连10步都不到。基本上,apache的东西和co制作的规则引擎几乎是正交的关系。拿functor自然不能说不能做规则引擎,就象我拿c#, java,ruby, python都能做一样。但是functor这个库里面对规则引擎这种高阶逻辑提供的有价值的支持和帮助几乎等于0。 我不知道你从哪里得到的这个“基于functor做规则引擎”的想法的。费解。 对不起,我也觉得你想当然了。我不知道你有没有看过Functor? 说出“连0步“都不能达到,我更觉得你武断。更想当然。 http://www-128.ibm.com/developerworks/cn/java/j-fp/ |
|
返回顶楼 | |