策略模式
问题
对于不同的选择,实现不同的功能,一个类中用if else 判断起来麻烦,倘若选择的方式庞杂,则这个类会比较庞大,难以维护,并且维护和扩展选择时,都需要修改原有的代码。
要求不同时候,实现不同的功能时,则又得需要修改if else 中的代码。
解决思路
把所有的选择方式独立出来,做成一个单独的算法类,从而形成一系列的算法;定义一个公共的接口,则这一系列算法都分别实现公共接口,实现各自的功能。
倘若添加新的选择方式,只需添加新的算法实现类;维护某个算法,也只修改某个算法的具体实现;从而实现程序的可扩展,可维护。
策略模式
- 定义
把具体的算法实现从具体的业务处理中独立出来,封装成单独的算法类,形成一系列的算法,并且这些算法可以相互替换。
策略模式的重心不是如何实现算法,而是如何组织、调用这些算法,从而让程序结构更灵活,更具有维护性和扩展性。多个if else if 可以考虑用策略模式
- 结构
- Strategy:策略接口,用来约束一系列具体的策略算法。
- ConcreteStrategy:具体的策略实现,即具体的算法实现。
- Context:上下文,和具体的策略类交互。通常上下文持有一个真正的策略实现
- 上下文负责持有算法,但是不负责决定具体选用哪个算法,把选择算法的功能交给客户,由客户选择具体的算法,设置到上下文对象中,并使用上下文对象执行功能,上下文对象则转调具体的算法。
/** * 策略接口,定义算法的接口 */ public interface Strategy { /** * 算法的接口 */ public void algorithmInterface(); } /** * 具体算法 */ public class ConcreteStrategyA implements Strategy{ @Override public void algorithmInterface() { //具体算法的实现 } } /** * 具体算法 */ public class ConcreteStrategyB implements Strategy{ @Override public void algorithmInterface() { //具体算法的实现 } } /** * 具体算法 */ public class ConcreteStrategyC implements Strategy{ @Override public void algorithmInterface() { //具体算法的实现 } } /** * 上下文对象 */ public class Context{ /** * 策略对象 */ private Strategy strategy = null; /** * 构造函数,传入具体的策略对象 * @param strategy 具体的策略对象 */ public Context(Strategy strategy){ this.strategy = strategy; } /** * 上下文对客户端提供的操作接口 */ public void algorithmInterface(){ //通常用 具体策略对象 进行算法 strategy.algorithmInterface(); } } /** * 客户端 */ public class Client{ public static void main(String[] args){ //使用A策略算法 Context context = new Context(new ConcreteStrategyA()); context.algorithmInterface(); } }
- 上下文负责持有算法,但是不负责决定具体选用哪个算法,把选择算法的功能交给客户,由客户选择具体的算法,设置到上下文对象中,并使用上下文对象执行功能,上下文对象则转调具体的算法。
简单----伊月海草