为何对于规则来说Java编码是不好的，而声明式编程是更好的选择

 

为何对于规则来说Java编码是不好的，而声明式编程是更好的选择 <o:p></o:p>

作者： Mark Proctor <o:p></o:p>

Drools的卖点之一，也是我们能够超越其它竞争者的地方是，在规则的表达式和推论中允许使用Java编码。这带来了一个较低的学习曲线，因为Java开发者不需要额外的培训就可以开始编写规则的推论部分；不管是更新值，发送消息或从数据库返回信息。这种与Java或类Java语言一体的模式，对于市场来说也是一种对比竞争者的宣传措施。从表面上看来起来是很好的，并且对于管理者来说也可以带来——更少的培训，利用现有的技术，哪不好的一面是什么呢？<o:p></o:p>

使用Java语言，将编程环境从一个产生式规则系统（如Drools）中转移出来。当你允许在规则中使用Java编码时，你也就开始使用命令式的编程。规则引擎提供了一个图灵完整的系统以及一种声明式的语言，如果你阅读了Drools用户手册回留意到我们花了一些时间解释命题和一阶逻辑，以及它们怎样可以用一种声明式的风格来描述各种情况——这对于软件开发者来说是一种不可思议的方法。概要来说Java是命令式的，因为你描述如何去做事情，这通常占据了多行的代码并且意味着你必须读完所有这些代码才能理解它要做什么。当代码变得越复杂，也就意味着你要阅读更多的代码行，最终从这一点来说，当复杂性越来越大时，代码将变得难以理解和维护；这就会造成只有最初的开发者才能有效率的维护代码。声明式编程允许你用关键字来表达复杂的规则；每一个规则特定于一个特殊场景以及相关行为之间的细节。这些行为也应该使用声明的模式来指定，否则会降低我们定义和编制规则条件的价值。这正是业务规则方法学的灵魂所在。对于这点感兴趣的朋友我推荐下面三本书：
Business Rules and Information Systems: Aligning IT with Business Goals
Tony Morgan
ISBN: 0201743914

Principles of the Business Rule Approach
Ronald G. Ross
ISBN: 0201788934

Business Rules Applied
Von Halle
ISBN: 0471412937

因此当我们开始将复杂的If嵌套架构和循环架构放入推论时，我们就开始增加维护的复杂性；取而代之的是推论应该专注于函数或者对象方法的调用。每一个函数或方法有着清晰和文档化的角色，它指定了需要的参数，它对这些参数的处理以及返回的值——它们也可以用DSL来表示的更清晰。<o:p></o:p>

当前Drools并没有计划移除对Java的支持，并且我们不久将希望增加Groovy和JavaScript的支持——我们也希望推荐一种支持声明式方法的语言，而不是从Drools中移除什么。这种新的语言将变成我们推荐编制规则的标准语言。<o:p></o:p>

那么这样的语言应该包括什么呢?<o:p></o:p>

<o:p> </o:p>

• 完整的表达式支持<o:p></o:p>

<o:p> </o:p>

• 自动封包和解包<o:p></o:p>

<o:p> </o:p>

• 对象方法调用<o:p></o:p>

<o:p> </o:p>

• 对象字段赋值<o:p></o:p>

<o:p> </o:p>

• 对象创建<o:p></o:p>

<o:p> </o:p>

• 简单的声明式数据结构<o:p></o:p>

<o:p> </o:p>

• 基本的if/switch/loop 支持(谨慎的使用)<o:p></o:p>

<o:p> </o:p>

我仍然犹豫是否要支持匿名类——当我们需要在对象上指定行为监听器或回调时需要使用。无论怎样，这显然增加了复杂度，我希望能够避免在推论中增加这个，可能使用一些其它方法建立在函数或方法之外。像if/switch/loop这样的控制结构可能也会被配置为可选的，或者设置一些使用障碍。这种语言应该能够同时工作在解释模式和编译模式。编译模式允许最大化的执行速度，对于小型或中型系统是理想情况——拥有数千条规则的大型系统将会遭受内存溢出问题，可能最好是使用解释模式。

<o:p></o:p>

注：在Drools4.0中作者已经使用MVEL作为这种新的语言。<o:p></o:p>