背景

计费零碎中的试算办法，为了兼容不同场景的计费规定，定义了CalculateCondition接口，不同的场景别离有各自CalculateCondition实现类，别离对应不同的逻辑

上面代码是目前的试算办法中的次要框架结构，别离用了3个if/else的分支判断逻辑，接下来的需要要新增加一个CalculateCondition的实现类及相应逻辑，就必须改变原有代码

......                CalculateCondition calculateCondition = request.getCalculateCondition();                if (calculateCondition instanceof CalculateBySingleCode) {                   ......                } else if (calculateCondition instanceof CalculateByMultiCodes) {                   ......                } else if (calculateCondition instanceof CalculateByRemainder) {                   ......                } else {                    throw new IllegalArgumentException("UnSupported calculateCondition .");                }......}

这种批改形式不够优雅并违反了OCP的设计准则，软件实体应该对扩大凋谢，对批改敞开。

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

-Bertrand Meyer

上面咱们将对下面这段代码进行优化，以此来实现OCP设计准则

设计

现实中的实现应该是基于这样的：


外围点只须要做好四件事

  1. 给不同conditoin加上各自的标识
  2. 给逻辑实现加上各自的标识
  3. 加载所有逻辑实现
  4. 依据标识获取相应的逻辑实现

实现

给condition加上标识

public interface CalculateCondition extends Serializable {    /**     * 试算条件key的惟一标识     */    String getConditionTag();}

不同的实现类返回不同的标识，以CalculateBySingleCode为例

public class CalculateBySingleCode implements CalculateCondition {    ......        @Override    public String getConditionTag() {        return CalculateTagType.SINGLE_FEE_CODE;    }}

给逻辑实现加上标识

@CalculateRouterExtension(calculateTag = CalculateTagType.SINGLE_FEE_CODE)public class SingleFeeCodeCalculateRouter extends AbsConditionCalculateRouter {    @Override    public Map<String, CalculateResult> calculate(ConditionCalculateParam param) {            ......    }......}

这里应用的是注解的形式，使得代码看起来更加直观

加载逻辑以及提供逻辑

@Componentpublic class CalculateRouterHolder {    private Map<String, AbsConditionCalculateRouter> routerRegistry = Maps.newHashMap();    @Autowired    public CalculateRouterHolder(List<AbsConditionCalculateRouter> routerList) {        routerList.forEach(router -> {            CalculateRouterExtension point = router.getClass().getAnnotation(CalculateRouterExtension.class);            if (point != null) {                routerRegistry.put(point.calculateTag(), router);            }        });    }    public AbsConditionCalculateRouter getCalculateRouter(String key) {        Preconditions.checkState(routerRegistry.containsKey(key), "UnSupported calculateCondition");        return routerRegistry.get(key);    }}

这里有个比拟奇妙的点是，间接利用Spring的@Autowired注解在办法上以此获取所有的逻辑实现

成果

至此，在调用方的成果就成了以下这样

  Map<String, CalculateResult> result = calculateRouterHolder.getCalculateRouter(                    request.getCalculateCondition().getConditionTag()).calculate(param);

当初当我须要新增加一个CalculateCondition的实现类的时候，只须要实现相应的逻辑实现类即可，不必在逻辑骨干代码上批改。从而晋升零碎的可维护性、可扩展性