设计模式思考之 Strategy 模式

431 阅读2分钟

这是我参与8月更文挑战的第26天,活动详情查看:8月更文挑战

Strategy也就是策略模式,和之前说的Bridge模式比较类似,都是实现与功能分离的模式。甚至可以说策略模式是桥接模式的子集,策略强调的是针对不同的场景提供不同的实现。无论是桥接还是策略,一个关键点在于委托。委托是一个比较弱的关联,被委托的接口或者抽象类可以有不同的实现,在主体对象中可以灵活切换实现。下面是策略模式的类图:

image.png

策略模式经常用于算法的热插拔,根据不同的计算结果动态的切换算法。在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"))
}

大清亡了,我感觉设计模式也该更新一下,适配函数式的理念了。