今天在正在作的项目中应用了Decorator模式，解决了代码扩展和维护的问题，问题需求如下：

平台对外提供SP加载接口，其中支付部分设计到N个接口，这些接口的DAO实现需要分解为很多子方法来实现，如何灵活的组织和分解这些DAO接口是个很关键的问题；

刚开始考虑用工厂对应不同的支付类型提供不同的实现，然后用工厂统一管理。

但实际现在的状况是平台每一次的支付并不是一次支付行为对应一种支付类型，而是每次支付都可能绑定多种支付类型，因此扩展类型来实现并不是一个很好的办法，但这也是问题，还没想好如何更好的处理这个问题。

于是考虑用装饰来对接口的实现根据不同的接口要求随意装配不同的DAO子接口实现，这是一个很典型的装饰模式：

SpChargeManager  ：Sp支付加载实现管理类，提供加载接口实现的统一入口，采用懒汉式单例模式实现

ICharge：平台支付接口定义类，定义了按次支付预处理、确认处理、包时段预处理、确认等sp接口规范定义的接口

SpChargeDecorator：Sp加载接口装饰类，实现了sp加载接口定义的各种支付方法，组合调用平台支付类的各个业务方法实现加载接口

 PlatCharge：平台支付接口实现类，扩展抽象了其他DAO需要处理的方法定义

 PlatSpCharge：平台支付所需子方法的实例类，用于各个Dao方法的调用组合，各个方法抛出跟sp支付相关的业务异常
 

这样就很好的解决了多个DAO业务层设计的问题。

发表于 @ 2006年12月29日 20:17:00|评论(loading...)|编辑