背景
计费零碎中的试算办法,为了兼容不同场景的计费规定,定义了 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 设计准则
设计
现实中的实现应该是基于这样的:
外围点只须要做好四件事
- 给不同 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 的实现类的时候,只须要实现相应的逻辑实现类即可,不必在逻辑骨干代码上批改。从而晋升零碎的可维护性、可扩展性