诊断Java代码: 设计可扩展应用程序,第3部分 - 编程入门网
中需要某一形式的黑盒可扩展性,而且您无需使用户负担过重就能提供这一可扩展性。在许多情况下,这仍需要先实现具有较窄范围的应用程序的不可扩展版本,然后再在另一个版本中添加可扩展性。
您可能觉得这有点自相矛盾。毕竟,添加可扩展性的所有目的是减少实现系统中新功能的花费。如果知道要扩展应用程序,那为什么不在开始时就构建可扩展性呢?因为构建不具备可扩展性的应用程序通常要便捷得多。 最初您能提供的应用程序版本越简单,客户就能越快地将它用于至少是他们的部分任务中。接着,您可以从 版本 1.0的销售中获得收益,来支持开发更具可扩展性的版本。 确定复杂性 考虑这一问题的关键是,您是否希望应用程序的可扩展版本在相当大的程度上要更为复杂。有时,设计应用程序的最简单最自然的方法就是合并可扩展性。 这里最好的示例之一是税收计算应用程序。这样的应用程序可以用于许多组税单。使用哪组特定表单取决于特定的用户;因此,使用特殊用途的配置语言来描述各种表单是很自然的。如果不是这样,而将这些税单硬连接到程序中(即,通过表单的类层次结构,其中每个表单有一个单独的 类),并不会减少复杂性。 但是,一旦用黑盒可扩展性这一方法设计了应用程序,则不必修改,甚至不用查看源代码,就能够方便地添加新的表单(当下一财政年度必须这样做时)。 还有其它一些应用程序示例,它们的黑盒可扩展设计是最简单的。可以想到的示例有:Web 浏览器,电视调度查看器(类似数字电视服务使用的查看器)和依赖于公理数据库的自动化定理证明器。 值得自豪的语言 现在,假设您已决定为应用程序的某些方面提供一种配置语言。在决定这样做时,需要确认的最重要一点是:要知道您是真的在设计一种语言。必须考虑与编程语言设计者有关的相同类型的问题。例如: 您的语言应该有一个正式的、定义明确的语法和语义。 该语言的解释器应该包括解析器,它会拒绝除语言中语法上有效规范以外的所有内容。 可能的话,应该允许进行某些与环境有关的检查,如类型检查。 请注意,这不是一个详尽的清单;还有许多其它注意事项。 某些人喜欢忽略其中一些步骤,即,不用太担心只接受语法上有效的代码。这是很普遍的。通常的结果是:很难跟踪这些语言的配置脚本中确实会突然出现的许多错误。(在我所写的“破坏者数据错误模式”一文中讨论了这一问题;请参阅 参考资料。) 遗憾的是,忽略这些步骤而产生的问题不仅仅是错误。一些最有破坏性的计算机安全性攻击(包括“红色代码(Code Red)”病毒)都是因未能正确解析输入而引起的。Ross Anderson 的 Security Engineering一书(请参阅 参考资料)包括了大量关于操作系统的环境中这样的攻击的讨论。 使用 XML 的优点 幸运的是,成功设计这样的语言已不再象以前那样困难了。XML 是用来实施这一任务的绝好工具,因为有许多现成的 XML 解析器和开发工具。 这些第三方组件不仅可以使您的工作更简便,而且还使开发人员能够更方便地将您的配置脚本重用于其它应用程序。例如,可以为药品大全应用程序编写各种分子的 XML 描述,然后可以(由无权访问原始应用程序的源代码的另一方)将这些描述重用于药品设计开发工具中。 顺便提一下,以这种方式重用代码也是必须很好定义配置语言的语义的另一个原因。如果程序的含义只能通过挖掘解释器的详细信息来确定,则重用脚本的花费会高得多。请参阅 参考资料,那里有几个非常好的 XML 工具的链接。 诊断Java代码: 设计可扩展应用程序,第3部分(3)时间:2011-02-11 IBM Eric E. Allen使用 XML 的缺点 使用 XML 存在一些缺点。用 XML 编写的脚本非常冗长,而且对某些形式的信息(如可执行代码)编码会很笨拙。同样,使用 XML |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |