策略模式不同，代码实现不同

策略模式

• 环境(Context)：持有一个 Strategy 的引用。
• 抽象策略(Strategy)：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
• 具体策略(ConcreteStrategy)：包装了相关的算法或行为。

有朋友可能会问了，这和工厂模式有什么区别吗？

我们再来看下工厂模式。

简单工厂模式：

看上去简直一摸一样吧。

其实工厂模式和设计模式一直给人一种错觉，总感觉是一样的，没有丝毫的区别。

直到我看到一个网友的解读：

工厂模式中只管生产实例，具体怎么使用工厂实例由调用方决定，策略模式是将生成实例的使用策略放在策略类中配置后才提供调用方使用。工厂模式调用方可以直接调用工厂实例的方法属性等，策略模式不能直接调用实例的方法属性，需要在策略类中封装策略后调用。

一个注重的是实例的生产，一个注重的是策略方法。

好了，这个时候再来看我们的代码，好像越来越复杂了，虽然用策略模式将具体的算法都抽离出来了，但是 if-else 的问题还是没有解决啊

思考一下，我们可不可以结合以下工厂模式，来去掉烦人的 if-else

可以把策略对象初始化到一个 map 进行管理

public interface PriceStrategy {
    Map<String, PriceStrategy> map = new ConcurrentHashMap(){{
        put("VIP", new VipPriceStrategy());
        put("S_VIP", new SVipPriceStrategy());
        put("BEGGAR_VIP", new BeggarVipPriceStrategy());
    }};

    Double computePrice(Double price);
}

public class PriceContext {
    private PriceStrategy priceStrategy;

    public PriceContext(String type) {
        this.priceStrategy = PriceStrategy.map.get(type);
    }

    public Double computePrice(Double price) {
        return priceStrategy.computePrice(price);
    }
}

外部调用

public Double computePrice(String type, Double price) {
    PriceContext priceContext = new PriceContext(type);
    return priceContext.computePrice(price);
}

舒服了，终于干掉了 if-else

策略模式优缺点

优点：

• 策略模式遵循开闭原则，实现代码的解耦合，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
• 算法的使用就和算法本身分开，符合单一职责原则

缺点：

• 客户端必须知道所有的策略类，并自行决定使用哪一个策略类
• 策略模式可能会造成系统产生很多具体策略类

总结

其实我们在工作中使用设计模式的时候，不需要被条条框框所束缚，设计模式可以有很多变种，也可以结合几种设计模式一起使用，别忘了使用设计模式的初衷是什么，不要为了使用设计模式而使用设计模式。