敏捷软件开发 - 原则、模式与实践 —— 设计模式（十）PROXY模式和STAIRWAY TO HEAVEN模式

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。

本文对应原书第26章

PROXY模式

图1

PROXY模式具有一个非常大的好处：重要关系的分离。在上面的例子中，业务规则和数据库就被完全分开了。在那些把业务 规则和数据库实现分离显得非常重要的情况中，PROXY模式是很适用的。就此而言，PROXY模式可以用来分离业务规则和任何种类的实现问题。它可以用来防止业务规则被诸如：COM、COBRA、EJB等东西污染。

使用代理是有代价的。规范模式中所隐含的简单委托模型很少能够被优美地实现。相反，我们经常会取消对于繁琐的获取和设置方法的委托。对于那些管理1：N关系的方法来说，我们会推迟委托并把它移到其他方法中。

大多数应用程序不需要代理。但是存在一些情况，其中代理所提供的的应用程序和API的极端分离是有益的。这些情况几乎总是会出现在那些遭受着频繁的数据库模式或者API变更的非常大型的系统中；或者出现在可以运行在许多不同的数据库引擎或者中间件引擎之上的系统中。

STAIRWAY TO HEAVEN模式

STAIRWAY TO HEAVEN模式是另一个可完全和PROXY模式一样的依赖关系倒置的模式。它使用类形式的ADAPTER模式的一个变体。

图2

PersistentObject是一个知道数据库的抽象类。它提供了两个抽象方法：read和write。它同时还提供了一组实现方法作为实现read和write所需要的工具。例如，在PersistentProduct的read和write的实现中，会使用这些工具把Product的所有数据字段从数据库中读出或者写入到数据库。同样，在PersistentAssembly的read和write的实现中，会对Assembly中的额外字段做相同的工作。它从PersistentProduct中继承了读写Product字段的能力并且把read和write方法组织成可以利用这个能力的形式。

这个模式只能在支持多重继承的语言中使用。请注意，PersistentProduct和PersistentAssembly都继承自两个已经实现的基类。此外，PersistentAssembly和Product之间是一个菱形继承的关系。

结论

远在真正需要PROXY模式或者STAIRWAY TO HEAVEN模式前，就去预测对于它们的需要是非常有诱惑力的。但这几乎从来都不是一个好主意，特别是对于Proxy模式。我建议在开始时先使用FACADE模式，然后在必要时进行重构。如果这样的话，就会为自己节省时间并省去麻烦。

完整内容请查看敏捷软件开发 - 原则、模式与实践系列