1设计模式的应用
上述３个问题虽然侧重点不同，但它们有着一个共同特点，即都属于非功能性问题，都涉及到软件的灵活性和可扩展性。显然，设计模式是解决该类问题的不二选择。然而，设计模式的描述主要是以自然语言结合ＯＯ框图的描述方法，一些语言描述有一定的歧义性，使设计者在为特定问题选择设计模式时往往会犹豫不决。虽然设计模式有许多优点，但是仍然需要人们掌握它的本质并学会正确的使用方法，才能够正确应用并真正发挥它的优势，同时应该避免滥用带来的软件结构的复杂性和冗余，不能为了使用模式而使用［２］。鉴于设计模式的复杂性，作者对第２节中提出的３个问题进行了抽象，并按照设计模式的分类方式进行了归类和匹配，从而提出分别用职责链模式、代理模式和桥接模式解决这３个问题。
2职责链模式
三维地形环境仿真系统具有实时性、交互性强等显著特点，如用户在场景中的鼠标操作需要由主控分发到多个组件，场景的相机位置发生改变需要通知到多个组件，等等。如何处理好主控与各个功能组件之间这种复杂的请求与反馈关系呢？作者经过分析，选择了“职责链模式”来解决这个问题。职责链模式（ＣｈａｉｎｏｆＲｅｓｐｏｎｓｉｂｉｌｉｔｙＰａｔｔｅｒｎ），是指使多个对象都有机会处理请求，同时避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止［３］。这种模式应用很广，它的最大优势是接收者和发送者都不需要对方的明确信息，即可完成请求的发送和处理。如图２所示，为职责链模式的ＵＭＬ图。然而，图２只是职责链的标准模式，它虽然具有很好的扩展性，可以使软件具有动态增加请求处理者的能力，但却存在着两个很现实的问题：在某些特殊情况下，可能有多个Ｈａｎｄｌｅｒ需要接受处理，也有可能某些Ｈａｎｄｌｅｒ允许或不允许其后继者继续处理请求（如在响应键盘事件时，某些组件试图锁定某些热键，不允许其后继组件使用，但并非锁定所有按键），图２中的标准模式是无法解决这个问题的。针对这两个问题，作者对图２中职责链的标准模式进行了改进，如图３所示。图３主要做了如下两点改进：１）针对问题１，使用发布－订购（Ｐｕｂｌｉｓｈ／Ｓｕｂ－ｓｃｒｉｂｅ）模式，只让对相关请求“感兴趣”的组件并实例化，这些组件需要预先订购这些请求，本文将其由“Ｈａｎｄｌｅｒ”更名为“Ｓｕｂｓｃｒｉｂｅｒ”（订购者）。这样，在发送请求时，３Ｄ主控只需要面向订购了该请求的组件，也就不会出现无用的Ｈａｎｄｌｅｒ了。２）针对问题２，为Ｓｕｂｓｃｒｉｂｅｒ的接口函数Ｈａｎ－ｄｌｅＲｅｑｕｅｓｔ（）增加一个ｂｏｏｌ型参数ｌｏｃｋ，表示当前处理者是否允许其后继者继续处理该请求，如果ｌｏｃｋ为ｔｒｕｅ，表示当前组件锁定该请求，职责链不再向下传递请求；否则，请求继续传递，直到ｌｏｃｋ再次为ｔｒｕｅ或职责链走到末端。这样就解决了多个Ｈａｎｄｌｅｒ需要处理请求或锁定请求的问题。
3代理模式
在三维地形环境基础平台中，很多组件都需要与地形数据发生交互，如果这些组件都直接去访问地形数据库或数据文件，不仅会造成大量的代码冗余，一旦数据格式发生改变，还会引发多个组件的多处改动。如何确保各个组件能通过统一的渠道访问到地形数据呢？作者经过分析，选择了“代理模式”来解决这个问题。代理模式（ＰｒｏｘｙＰａｔｔｅｒｎ），是指为其它对象提供一种代理，以控制对这个对象的访问［３］。如图４所示，为代理模式的ＵＭＬ图。ＤＢＰｒｏｘｙ接口：定义了ＤＢ（数据库）和ＤＢ－Ｐｒｏｘｙ（数据库代理）的共用接口，这样在任何需要使用地形数据（即需要调用ＤＢ）的地方都可以使用ＤＢＰｒｏｘｙ，所有需要与地形数据交互的组件只需要通过统一的ＤＢＰｒｏｘｙ接口即可，而无需了解ＤＢ本身的格式或格式是否发生了变化；ＤＢ类：定义ＤＢＰｒｏｘｙ类所代表的真实实体；ＤＢＰｒｏｘｙ类：保存一个引用使得代理可以访问实体，并提供一个与ＤＢＰｒｏｘｙ的接口相同的接口，这样代理就可以用来代替实体。与２．１节中讨论的职责链模式相比，代理模式的思路和实现方法都比较简单，唯一需要注意的是，由于需要确保通过统一的接口访问地形数据，因此，必须结合“单实例模式”，确保整个系统运行过程中无论有多少客户端，ＤＢＰｒｏｘｙ都只能有一个。单实例模式（ＳｉｎｇｌｅｔｏｎＰａｔｔｅｒｎ），是指保证一个类仅有一个实例，并提供一个访问它的全局访问点［３］。
4桥接模式
一个具有很好通用性的三维地形环境基础平台，需要能支持多源异构的地形数据，而仅仅依靠代理模式是不够的。因为该模式只是解决了如何通过统一接口访问地形数据的问题，至于数据库代理（ＤＢＰｒｏｘｙ）如何取到这些数据，数据是什么结构，存储于什么位置，这不是数据库代理能够解决的问题，也并非其职责所在。作者经过分析，选择了“桥接模式”来解决这个问题。桥接模式（ＢｒｉｄｇｅＰａｔｔｅｒｎ），是指将抽象部分与它的实现部分分离，使它们都可以独立地变化［３］。当一个抽象可能有多个实现时，通常用继承类协调它们，从而将抽象部分与其实现部分紧紧耦合在一起，难以对抽象部分和它的实现部分独立地进行修改和扩充。而桥接模式则通过将接口和实现部分分离，提高了可扩充性，同时还可以将实现细节对用户透明［４］。如图６所示，为桥接模式的ＵＭＬ图。其中：Ａｂｓｔｒａｃｔｉｏｎ接口表示抽象部分，Ｉｍｐｌｅ－ｍｅｎｔｏｒ接口表示实现部分；ＲｅｆｉｎｄｅｄＡｂｓｔｒａｃｔｉｏｎ类表示被提炼的抽象，ＣｏｎｃｒｅｔｅＩｍｐｌｅｍｅｎｔｏｒＡ和ＣｏｎｃｒｅｔｅＩｍｐｌｅｍｅｎｔｏｒＢ表示具体的实现。利用桥接模式的优势，作者设计了一种基于桥接模式和交换模型的多源异构数据获取方式（见图７所示），基本思路如下：１）定义一个数据提供者接口（ＤａｔａＰｒｏｖｉｄｅｒ），为数据库代理组件（ＤＢＰｒｏｘｙ）提供各种来源的地形数据。通过这种方式，在ＤＢＰｒｏｘｙ和各个异构数据源（如图７中的ＤａｔａＰｒｏｖｉｄｅｒ１和ＤａｔａＰｒｏｖｉｄｅｒ２）之间架起了一座“桥梁”，从而避免了数据库代理直接访问各个数据源，实现了代理与数据源的松耦合，这就是桥接模式的主旨所在。２）定义交换数据模型。如图７中的ＴｒａｎｓＭｏｄｅｌＤｅｍ和ＴｒａｎｓＭｏｄｅｌＩｍｇ，分别表示交换模型中的Ｄｅｍ数据和纹理数据。设计交换数据模型的目的，是为了使各个ＤａｔａＰｒｏｖｉｄｅｒ能在根据指定的参数（如地理范围、分辨率等）获取到自己内部格式的数据模型后，将内部格式转换为一种统一格式的数据模型，返回给数据库代理。这种统一格式的数据格式，就是作者所设计的交换数据模型。它实现了数据库代理组件与各异构数据源之间的松耦合，达到了减小组件粒度，提高重用性的目的。
5结束语
设计模式是软件工程中的重要研究方向，它能有效解决软件设计中的可复用性和可扩展性等问题［６］。本文首先分析了三维地形环境仿真平台的特点，然后将设计模式引入平台的设计，分别用职责链模式、代理模式和桥接模式解决了平台设计中存在的３个主要问题。实践表明，设计模式可以有效提高软件的可维护性和可扩展性。
作者：杜莹 龚桂荣 陈刚 单位：信息工程大学 测绘学院
相关专题：商标翻译 兰州新闻物流商会捐物
