东阳做网站的公司seo优化运营

Andy Carlson, Sharon Estepp, Martin Fowler 著，透明 译

抽象

在面向对象设计中，我们不断使用“对象”（object）这个词。对象不仅仅用来表现真实世界中存在的物件，它们也被用来表现那些曾经存在但已经消失了的物件，以及那些可能存在于未来的物件。
上述的要求给我们的建模工作提出了一个特别的挑战，因为如果建模者必须考虑物件随着时间的变化情况，出现在某一特定时间点的对象的复杂度就会大大增加。

这篇文章将向读者介绍三个模式，并通过它们向读者展示怎样通过改进对象模型来解决上述问题，以及最终得到的模型怎样为那些不关心时效问题的客户提供支持。

模式一：Temporal Property（时效属性）模式

别名：历史映射（Historical Mapping）

环境

假设你正在建设一个复杂的信息系统，其中对象的属性必须可以随时间变化而变化。另外你还需要可以跟踪：

1、属性在过去怎样变化？

或2、属性在未来将怎样变化？

或3、以上两点。

很自然的，你会让这个属性包含一系列离散值，用这些离散值来表示时间间隔对属性的影响（不能用这个方法来表示象温度这样可以连续变化的属性）。为了实现这个系统，你还可能需要使用某些数据库（可能是关系数据库）。

问题

在考虑“对象怎样随时间变化”时，通常我们的意思是“它的属性怎样随时间变化”。这些属性（property）可能是变量（attribute）、关联（relationship）或者查询操作（query operation）。例如，请考虑图1所示的模型：

在这个模型中，我们关心雇员的两个属性：他的工资和他的技能。于是我们得到了图2所示的Employee接口：

 

我们也不排除给Skill类提供一个相似的接口的可能性，如果那样做的确有用的话。

现在，我们来看看怎样让这个类体系支持变化，从而让我们可以记录某雇员以前的工资和技能、可以预测未来需要的雇员的工资和技能。

正如图3所示的，我们给Employee类的属性加上了Time Period（时间段）这个修饰。以Salary为例，我们必须创建一个单独的类来保存工资值，并用一个与之相关的Time Period指出这个工资值有效的时间段。

这样，我们就可以允许多个Salary与同一个Employee发生联系（它们拥有不同的时间段）。再以Skill为例，这个类的一个实例可以被许多Employee的实例共享，所以有必要引入一个中间对象来保存相关的TimePeriod信息。