探索实践之软件构建（三）

活用适配器模式

    Adapter模式关键特征

意图：使控制范围之外的一个原有对象与某个接口匹配。

问题：系统的数据和行为都正确，但接口不符。通常用于必须从抽象类派生时。

解决方案：Adapter模式提供了具有所需接口的包装类。

--摘自《设计模式解析》的小片段。其实在实际应用中，还可以活用。在成本分配中，待分配费用（通常为间接的共耗费用）如果是从数据库查询出来的RowSet,可以分解、包装为具有业务意义名称、提供默认实现的接口和适配器方法。例如：

public interface IFeeInfo { getCostCenterID(); //取得成本中心ID getCostObjectID(); //取得成本对象ID getQtyPrecision(); //取得数量精度 getPricePrecision(); //取得价格精度 getAmountPrecision(); //取得金额精度 // ...... } public class FeeInfoAdapter implements IFeeInfo { private RowSet _allocatingData; public String getCostCenterID(); //取得成本中心ID { try { return _allocatingData.getString("costCenter.id"); }catch(SQLException e){return "";} } public String getCostObjectID(); //取得成本对象ID { try { return _allocatingData.getString("costObject.id"); }catch(SQLException e){return "";} } public int getQtyPrecision(); //取得数量精度 { try { return _allocatingData.getInt("measureUnit.qtyPrecision"); }catch(SQLException e){return 0; } } public int getPricePrecision(); //取得价格精度 { try { return _allocatingData.getInt("material.pricePrecision"); }catch(SQLException e){return 0; } } public int getAmountPrecision(); //取得金额精度 { try { return _allocatingData.getInt("currency.precision"); }catch(SQLException e){return 0; } } // ...... }

 

这样适配后的方法，如getCostCenterID就比不适配而直接在RowSet _allocatingData上操作要优雅许多了。

其实这个实现还是有不足的，因为_allocatingData是某个具体分配的待分配查询出来的，例如其它费用分配，如果开发员给它的那一列名不叫costCenter.id,而且叫costCenterOrgUnit.id,则getCostCenterID()实现就会取不到正确值了。也就是说，此实现违背了依赖倒置原则(DIP)：抽象的FeeInfo不应该依赖于各具体的分配查询的RowSet。

    更好的改进是去掉抽象层的硬编码的字段名，或者把目前带有硬编码字段名的实现作为默认实现，而再增加一个重载的方法，例如：

public String getCostCenterID(String feildName) { try { return _allocatingData.getString(feildName); } catch (SQLException e) { return ""; } }

 

在作设计时，切记要消除硬编码、魔术数字之类的，并作出变化的预计。消除硬编码常用的办法有：

1、把硬编码作为protected实例字段，例如上面的例子可以有_costCenterID变量；

2、作为protected getter方法；

3、有时用正则表达式可以消除；

4、有时用反射API可以达到效果。