正如“问题”一节所说，如果有必要，我们不排除为Skill类提供一个类似的接口的可能性。由于使用
了《temporal》版型，“问题”一节中复杂的图变得简单多了（见图7）。

图7：使用版型后的Employee模型

效果

√ 我们为原始模型添加了表现属性随时间变化的能力。

√ 通过使用《temporal》版型表示时效支持解决方案，我们重新得到了原始模型的简洁性。

√ 与简洁性一起，我们还重新得到了原始模型的可表达性（expressiveness）——现在我们可以断定：一个Employee可以同时拥有超过一个的Salary。

√ 我们把关于关联表达（relationship's representation）的主要信息都放在PropertyOwner中，从而确保其他的客户不会与此表达发生紧耦合。

√ 使用这个模式暗示着：对拥有时效属性的对象建模过程将更有一致性。

√ “未来值（future value）”将变成“当前值（current value）”，然后再变成“历史值（historical value）”，这些变化都会随着时间流逝自行发生，不需要对任何存储信息做任何更新。

× 如果你需要关联中间对象更多的信息（例如：EmployeeSkill类中某个技能的级别），本模式将不能满足你。你的需求指出了对中间对象的第一个类的需求，这可能指出了对Temporal Association模式的需求。

实现

本模式最简单的实现包括了对一个关联对象（PropertyAllocation）的创建,其中在PropertyOwner和
Property之间使用了一个Time Period对象（如图8所示）。 

图8：用PropertyAllocation对象实现Temporal Property模式

在这里你可以确定：Property实例不能在没有PropertyOwner实例存在的情况下单独存在；如果只有一个PropertyOwner类，Time Period可以直接附着到专用Property对象（DedicatiedProperty）上。具体的情况如图9所示。

 

图9：Temporal Property模式实现专用属性（dedicated property）

作为一种选择，你可能发现使用一个特制的Temporal Collection类对实现本模式是有用的。当不能使用关系数据库时，这种实现方式是最合适的。

使用关系数据库实现本模式时，你通常需要提供一个类和相应的数据表（table）来保存表现类关联所需的信息。但当可以使用专用属性实现时，这也是可以避免的。在这种案例中，你可以把时间域包含在属性类/表中。如果拥有者对象（owning object）和专用属性对象之间的关系总是一对一的，情况还可以进一步简化。在这种情况下，你可以假设一个属性（旧的）的结束时间是下一个（新的）属性的开始时间，于是你可以免去对结束时间的储存和维护。