转载

OCP原则的一次优化实践

背景

计费系统中的试算方法，为了兼容不同场景的计费规则，定义了CalculateCondition接口，不同的场景分别有各自CalculateCondition实现类，分别对应不同的逻辑

OCP原则的一次优化实践

下面代码是目前的试算方法中的主要框架结构，分别用了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的设计原则，软件实体应该对扩展开放，对修改关闭。

 -Bertrand Meyer

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

设计

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

OCP原则的一次优化实践

核心点只需要做好四件事

给不同conditoin加上各自的标识
给逻辑实现加上各自的标识
加载所有逻辑实现
根据标识获取相应的逻辑实现

实现

给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的实现类的时候，只需要实现相应的逻辑实现类即可，不用在逻辑主干代码上修改。从而提升系统的可维护性、可扩展性

OCP原则的一次优化实践

原文 https://segmentfault.com/a/1190000023370983

正文到此结束

所属分类： Java 编程技术

本文标签： spring CEO id 需求 IO 代码 ACE IDE http UI src rand map 软件 tag list zab https key HashMap
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二