Temporal（时效）模式02

使用这个模型，我们可以表现如下的信息：

􀁺􀀃 Dinsdale Piranha于1998年1月1日进入公司，那时的工资是$75,000；然后在1998年4月1日得到提升，薪水升到$85,000。
􀁺􀀃 Dinsdale于1998年3月1日参加了一个自信训练课程，从此他的技能中加上了“自信”这一条。
现在，假设我们希望知道Dinsdale在1998年2月1日拿多少工资。为了获得这一信息，我们可以检查Dinsdale所有的Salary对象，找到包括“1998年2月1日”这一日期的那个对象——那就是我们关心的。相似的，我们也可以从EmployeesSkill对象中找到Dinsdale在2月1日的技能。在这个例子中，我们很可能找到不止一个Skill对象。

我们还可以很轻松的给Dinsdale指定一个未来的工资（比方说，为了做他的1999年度薪酬展望2），只需要创建一个时间区段从1999年1月1日开始的Salary对象就可以了。

现在我们的模型得到了我们需要的表达能力，但我们必须付出如下的代价：

􀁺􀀃 从前我们只有两个类、一个联系、一个属性，现在我们有了5个类、5个联系和一个约束。

􀁺􀀃 为了回答关于任何时间点的问题（包括“现在”），我们必须取得并处理比从前多得多的对象。

􀁺􀀃 我们失去了原来模型的透明度，尤其是在关心集的容量（cardinality）时：我们不再能轻易断定一个雇员是否可以在同一时刻拥有一份或多份薪水。

总而言之，这个模型的时效方面的改进把其他方面的优点都淹没了。实际上，应用系统中的时效联系比我们这里的多得多。我们把这作为一道练习题留给你：确定一个应用系统中支持时效所需的类、属性和联系的数量。

约束

􀁺􀀃 简单的模型更具吸引力——开发者通常都有“保持事情简单（keep things simple）”的愿望。
他们希望在设计时使用最小数量的类和关联，并且尽量不关心时效方面的问题。

􀁺􀀃 简单的模型有时候是不够的——有时候，的确会有变化跟踪（change track）的需要（对于对
象的过去和未来的跟踪）。

􀁺􀀃 复杂的模型将不那么清楚——模型的本质可能会被时效部分隐藏起来。

􀁺􀀃 变化的影响——类之间关系的表现形式会发生改变，这会导致的代价是：所有的客户——如
果他依赖于对此表现形式的了解——都必须做相应的改变。

解决方案

为每个需要跟踪其变化的属性建立一个模型（就象“问题”一节中的模型那样），用此模型来表现属
性的有效时间段。本模式有几种可选的实现方法，所以我不可能在这里给出一个抽象结构图——如果不使用一个版型（stereotype）（后面将给出一个版型）。“实现”一节中包含了一些可选的模型。

确定了一个模型之后，你应该尽量让客户容易操纵它，因此你应该把时效部分隐藏在一个方便的接口后面，接口中只应该包括客户感兴趣的属性。你还应该为不关心时效功能的客户提供支持，因此你应该添加不需要时间参数的方法，并为这些方法设定一个默认时间值。这个接口如图4所示：

如果你使用的建模符号允许（就象上面的UML这样），使用一个叫做《temporal》的版型可以进一步简化模型结构（见图5）。

 

在我们的例子中，“工资”和“技能”属性可以通过如图6所示的接口进行访问。