第Ⅰ部分 设计模式
第1章 动态对象模型
1.4 问题
动态对象模型（DYNAMIC OBJECT MODEL）模式解决了很多不同的问题。有些系统只
存在其中的一个或几个问题：
一个系统是很难理解、改变和发展的，因为它很复杂。由于有太多类型的对象，系统可能更复杂，但其实它们只在少数几个方面有所区别。
系统需要经常变化和迅速发展，新类型的对象必须在运行时创建。例如，最终用户可能需要指定这些新类型的对象，也需要立即将对象与原有系统结合，而不需要重建系统。
系统需要特定于域的建模语言，可能是因为它是由最终用户使用，也可能是因为它需要自定义的类型验证，还可能是因为它需要从模型生成复杂的行为。
通常是一个动态对象模型的出发点是使系统更加简单和更容易改变。后来则很明显，用户通过该模式不涉及编程即可指定变化，现在该系统则包含特定领域的建模语言。但是，有些动态对象模型不允许最终用户定义新类型，有时是动态对象模型以对特定领域建模语言的需要开始。
Smalltalk等语言支持在运行时修改类，即使在类有实例时也可以修改。还允许开发人员在一定范围内适应（改编）元模型描述——类是什么样子以及如何运作。另一方面，类Java语言在这方面更为有限，甚至不考虑多重环境中串行化所引起的类不兼容的问题。那么为什么不使用上述某种动态编程语言呢？首先，许多客户已经固定使用一种或几种常用语言（通常是静态的），通常不会选择引入另一种语言。但更深刻的问题在于，它涉及的不仅仅是选择合适实现语言的技术问题。一般来讲，使用动态对象模型主要的根本动机，是使解决方案的“配置”更接近最终用户。1.10节给出了一些示例，例如域专家深入参与开发最终用户应用程序的过程。对这些用户应用通用编程语言和传统集成开发环境，会偏离既定目标。因此，动态对象模型驱动的系统往往伴随一套特定领域的高层次开发工具。
展开
