这是我参与8月更文挑战的第26天,活动详情查看:8月更文挑战
Strategy也就是策略模式,和之前说的Bridge模式比较类似,都是实现与功能分离的模式。甚至可以说策略模式是桥接模式的子集,策略强调的是针对不同的场景提供不同的实现。无论是桥接还是策略,一个关键点在于委托。委托是一个比较弱的关联,被委托的接口或者抽象类可以有不同的实现,在主体对象中可以灵活切换实现。下面是策略模式的类图:
策略模式经常用于算法的热插拔,根据不同的计算结果动态的切换算法。在AI模型的验证中比较有用,在同一场景不同选项返回不同计算逻辑的时候也十分有用,比如在高德地图中查询某个线路,当你点击步行、自行车、汽车等等的不同选项时,它会动态的返回对应的路线规划,这是策略模式最常见的例证。
策略模式的代码跟桥接模式十分类似,就不再重写写了。这里介绍一种比较高效的实现——枚举实现。
public enum StrategyEnum {
WALK {
@Override
public Route buildRoute(String a, String b) {
Route r = doingSomething...
return r;
}
},
CAR {
@Override
public Route buildRoute(String a, String b) {
Route r = doingSomething...
return r;
}
};
public abstract Route buildRoute(String src, String dest);
public static void main(String[] args) {
Route route1 = StrategyEnum.WALK.buildRoute("a", "b");
System.out.println(route1);
Route route2 = StrategyEnum.CAR.buildRoute("a", "b");
System.out.println(route2);
}
}
这样实现起来看起来相对来说比硬编码要高效和优雅很多,但站在现在这个时间点上,再用这种方式就略嫌啰嗦了。Java在进步,在向函数式语言学习,所以现在可以通过函数来传递了。没错,就是Supplier,或者Function。比如下面这样的:
public class Strategy {
public Route runStrategy(Supplier<Route> s) {
...
}
}
public class Business {
private Strategy strategy;
Route route1 = strategy.runStrategy(()->buildRoute("a","b"))
}
大清亡了,我感觉设计模式也该更新一下,适配函数式的理念了。