实现

通过在树状层次构架中使用活动对象模型，可以把产品编辑器当作普通面向对象应用来实现。

相关模式

要实现产品编辑器，你应该使用产品树，而产品树用对象事件补偿模式组织。你还需要把表格系统和规则系统集成到其中。运行时系统可以采用实现虚拟机所采用的模式。前端部件用来为产品定义提供不同的产品视图。

要为产品编辑器实现产品商务模型，可以采用活动对象模型和发射。

已知应用

采用产品服务器的这种思想可以在许多保险系统中找到。VP/MS 中可以看到部分，如采用CAF 的产品定义。

EA Generali 实现的两个项目也包含了产品服务器的思想：KPS/S，一个正在开发财产保险项目；Phoenix，一个快要完成的人寿保险系统。

模式：规则系统

举例

假如你实现了一个产品编辑器，这个产品编辑器允许你定义产品结构，那么你需要一种机制来为树的节点元素从一种属性导出另一种属性，比如评估政策参数。

问题

你如何来实现真实性检查或者对产品树进行政策评估这样的功能？

动机

系统管理员的使用：如果你打算让你的系统管理员不编码就定义新产品，你必要提供一种解释语言，这种语言能够把产品属性，性能估计连接起来并且可以实现表格查找。如果你按照这个想法去开始你的工作，你很早就会发现这需要一种全新地编程语言才行。有关这些的进一步讨论可以参看WWW 上的《通过编程实现可定制》"(http://c2.com)。那里的讨论与《硬编码对脚本编程语言》相似：一般硬编码（尤其在Smalltalk）比试图在Smalltalk上再建立一种Smalltalk 容易。

代价：草率地开发一个规则系统是昂贵的冒险。给一些系统管理员培训Smalltalk 一般比为他们开发一种可定制的编程语言代价少。另外我们知，道，像Excel 那样，按可以接受的代价来实现像公式解释器那样的功能也常常为系统管理员乐意接受。

追溯机制的完成：如果要建立一个规则系统，最好使之能够完成产品定义需要的所有属性导出，否则，你就得编程实现。

灵活性：对于像C++那样的编译语言，要编辑/编译/链接才能完成，对系统管理员来说一个Excel 表单似乎灵活的多。

测试和调试产品：如果你要在你的产品定义中实现脚本语言一样的编码属性追溯机制，你需要一些其它编程语言环境，以及额外的工具，比如可定制调试器。

方案

建立一个类似于解析树中的语义功能的属性追溯机制，或者Excell 表单中的单元计算，在运行时解释。

结构

参看图6：保险产品树。如同编译建造，你可以使用某种编程语言（如Lex/Yacc)为语义功能编制程序，或者你也可以用各种不同脚本语言定义一套完整的工具。

注意，这跟基于规则的系统，比如人寿保险中的风险评估系统，没有太大的关系。在基于规则的系统中，你经常可以看到专家系统（如以Prolog 实现的）。我们这里谈到的规则系统在一个相当确定并且可预期的基础上实现商务规则。

结论

结论如同实现途径一样多种多样，究竟如何使用取决于你的动机。这些方面跟编程语言设计非常相似。这里给出一些示例，在我所知道的系统中，这些示例将要发生或者已经发生：

不完全规则定义语言：这种情况下，你将需要部分编码来完成属性追溯和定义，这样的结果是，相对它所提供的灵活性和可定制性，你付出了太高的代价。

超完全规则定义语言：这样一个非常复杂的语言容易出错并且相当昂贵。与其这样还不如使用解释性编程语言。