前言

在软件开发中，设计模式是为了解决常见问题而提供的一套可重用的解决方案。策略模式（Strategy Pattern）是其中一种常见的设计模式，它属于行为型模式。该模式的核心思想是将不同的算法封装成独立的策略类，使得它们可以相互替换，而不影响客户端的使用。

策略模式与其他设计模式有一些明显的区别。与模板方法模式相比，策略模式强调算法的灵活性，允许在运行时切换不同的策略。与状态模式相比，策略模式更注重不同算法之间的替换性，而非状态的内部转换。

优缺点

优点
策略类之间相互独立，易于扩展和维护。

可以在运行时动态切换策略，灵活性高。

提供了一种可替代继承的方案，避免继承层次的臃肿。

缺点
客户端需要了解不同的策略类，增加了使用的复杂度。

策略模式增加了类的数量，可能会导致系统更加庞大。

使用场景

如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为
一个系统需要动态地在几种算法中选择一种
如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现
如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题

角色定义

• 策略Context(上下文)

策略模式定义上下文角色本意是为了通过不同策略对象让上下文调用对应的算法或行为。

• 策略抽象

策略抽象主要设定行为，定义策略需要具有哪些行为。

• 策略实现

具体策略的实现，实现策略抽象行为具体细节。

UML

• FruitMarket(策略抽象)
• PapayaPeddler、KiwifruitPeddler、WatermelonPeddler(策略算法实现)
• SellFruitsContext(策略Context)

模拟示例

//卖水果策略 上下文
public class SellFruitsContext{//水果市场策略抽象private FruitMarket fruitMarket;public SellFruitsContext() {}public SellFruitsContext(FruitMarket fruitMarket) {this.fruitMarket = fruitMarket;}//调用策略方法public void sellFruit(){this.fruitMarket.sellFruits();}
}

//水果市场 策略抽象
public interface FruitMarket {void sellFruits();
}

//策略实现者
public class KiwifruitPeddler implements FruitMarket {public void sellFruits() {System.out.println("卖猕猴桃咯，保熟！！");}
}public class PapayaPeddler  implements FruitMarket {public void sellFruits() {System.out.println("卖木瓜咯，瓜保熟！！");}
}public class WatermelonPeddler implements FruitMarket {public void sellFruits() {System.out.println("卖西瓜咯，瓜保熟！！");}
}

//定义类型枚举 通过 类型获取 对应的策略算法
public enum FruitEnum {KIWIFRUIT(1,KiwifruitPeddler.class),PAPAYA(2,PapayaPeddler.class),WATERMELON(3,WatermelonPeddler.class);//水果类型private Integer fruitType;//水果类型对应的策略算法private Class c;FruitEnum() {}FruitEnum(Integer fruitType, Class c) {this.fruitType = fruitType;this.c = c;}public FruitEnum getFruitEnumByType(Integer fruitType){for (FruitEnum value : FruitEnum.values()) {if(value.fruitType==fruitType)return value;}return null;}
}

小结

通过类型在枚举类获取对应策略算法实现类，将策略算法实现类传入策略上下文，通过策略上下文调用具体的策略算法。后期业务扩展可新增枚举数据添加策略算法实现类，完成对扩展业务的实现。

策略模式在代码重构的时候是很常见的，减少大量if else代码、增强代码扩展性、策略算法的灵活切换、避免单个条件重复判断，很多情况选择switch以及if else会比较多，但是随着业务复杂度业务代码量上来了，随之代码的扩展性以及可读性降低代码也显得极其臃肿，虽说对于每一种算法都要为其建立一种策略类，相对比较懒的程序员更愿意写if else，有时候也不要觉得策略算法实现类太多，因为策略算法的多少取决于你的业务复杂度，正是因为策略算法很多才体现出业务的复杂,才更需要用好策略模式。