State模式在客户端软件中的应用

　　在对一个J2EE项目的重构、增加新功能的过程中，对客户端GUI程序，我们使用了State模式。结果显示，该模式的使用，不但减少了客户端GUI程序的程序规模(LOC)，而且，该部分的开发及单元测试时间大大减少，同时，在集成测试中发现的缺陷数量比使用该模式前平均减少了3倍。本文就该项目中使用State模式的方式进行介绍。

　　引言

　　在分层软件体系结构中，服务端程序关注于实现业务逻辑，客户端程序则包含用户界面。服务端程序由客户端程序调用，其请求、响应模式在设计时已经确定，运行时出现问题的概率较小。相反，客户端程序与用户直接交互，虽然有正确规定的操作顺序或模式，但是用户的操作是不可预知的，程序必须处理各种操作错误、加上数据输入有效验证等要求，使得客户端程序的开发成本上升。

　　因而，一旦有经过充分测试的、甚至是通过验收的用户交互程序GUI，应该尽可能的重用该GUI，以提高软件的可靠性、可维护性。

　　在对一个J2EE项目的重构、增加新功能的过程中，对客户端GUI程序，我们使用了State模式。结果显示，该模式的使用，不但减少了客户端GUI程序的程序规模(LOC)，而且，该部分的开发及单元测试时间大大减少，同时，在集成测试中发现的缺陷数量比使用该模式前平均减少了3倍。本文就该项目中使用State模式的方式进行介绍。

　　1. State模式

　　首先，先简单介绍一下State模式。

　　该模式是指在对象的内部状态改变时改变对象的行为【1】。其结构如图1所示。

　　图1 State模式结构

　　模式中各个参与者职责简介如下：

　　Context：用户对象，拥有一个State类型的成员，以标识对象的当前状态;

　　State：接口或基类，封装与Context的特定状态相关的行为;

　　ConcreteState：接口实现类或子类，实现了一个与Context某个状态相关的行为。

　　运行时，Context将与状态相关的请求委托给当前的ConcreteState对象处理。关于State模式更详尽的介绍，请参阅参考文献1。

　　2. 客户端应用

　　本模式的目标是分离客户端软件中的变化部分与不变部分，以使得变化的部分可独立于不变的部分，有利于扩充新的功能，也有利于维护。

　　在项目中，对于客户端GUI的重用有两种方式。

　　方式1适用于：相同数据集合，不同操作模式;此时，在GUI中定义客户端数据处理验证逻辑，不同的状态对象封装了不同的操作模式;

　　方式2适用于：不同数据集合，相同操作模式;此时，在状态对象中定义客户端数据处理验证逻辑，不同的状态对象封装了不同的数据集合操作。

[1] [2] [3] 下一页