怎样少写一点if...else...
2019-03-15 本文已影响14人
日更专用小马甲
在代码里直接加一个逻辑分支的诱惑力,有时候可能是局外人难以想象的,就像夏天吃小龙虾时候的喝的冰可乐,美味却代价昂贵(一瓶可乐半瓶糖~)。以至于最近在做Code Review的时候,发现有一段代码里差不多有10个逻辑分支。
其实以前团队是有个不成文的“竞赛”的:
比谁在代码里写的
if
少。
比如业务里有多组定价策略。一开始可能就这么写了。
if (strategy == Prince.StrategyA) {
…
} else if (strategy == Prince.StrategyB) {
…
} else {
…
}
如果再来一种策略就再加个分支。其实把各个策略通过多态封装在各自的实现类里,并把实现类“注册”到分发器(Dispatcher)里可以实现的稍微优雅一点。
public class Dispatcher {
Map<String, PrinceStrategy> strategies;
…
// 分发执行
PrinceStrategy princeStrategy = strategies.get(strategy)
priceStrategy.doPrincing()
}
开头提到的10多个逻辑分支的场景,其实是因为任务状态从一开始的3个慢慢的膨胀,而每次的应对方式都是在原来的代码里面增加一小段分支。其实是一种很适合用状态机模式重构的场景。
从表面看,无论方式,代码还是哪些代码,只是拆分到了不同类里。
但是最近突然有点感悟:其实这两种方式更侧重于为了满足“开闭原则”:当需要实现拓展的时候,对于原来的代码基本上不需要进行改动,造成的风险更小,测试回归的成本自然也就更低。