关于java:OCP原则的一次优化实践

背景

计费零碎中的试算办法，为了兼容不同场景的计费规定，定义了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) {
            ......
    }
......
}

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

加载逻辑以及提供逻辑

@Component
public 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的实现类的时候，只须要实现相应的逻辑实现类即可，不必在逻辑骨干代码上批改。从而晋升零碎的可维护性、可扩展性