山西百度网站建设,做网站的app,大连建设工程,如何做外贸营销型网站推广23种策略模式之策略模式 文章目录 23种策略模式之策略模式前言优缺点使用场景角色定义UML模拟示例小结 前言
在软件开发中#xff0c;设计模式是为了解决常见问题而提供的一套可重用的解决方案。策略模式#xff08;Strategy Pattern#xff09;是其中一种常见的设计模式设计模式是为了解决常见问题而提供的一套可重用的解决方案。策略模式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.fruitTypefruitType)return value;}return null;}
}小结
通过类型在枚举类获取对应策略算法实现类将策略算法实现类传入策略上下文通过策略上下文调用具体的策略算法。后期业务扩展可新增枚举数据添加策略算法实现类完成对扩展业务的实现。
策略模式在代码重构的时候是很常见的减少大量if else代码、增强代码扩展性、策略算法的灵活切换、避免单个条件重复判断很多情况选择switch以及if else会比较多但是随着业务复杂度业务代码量上来了随之代码的扩展性以及可读性降低代码也显得极其臃肿虽说对于每一种算法都要为其建立一种策略类相对比较懒的程序员更愿意写if else有时候也不要觉得策略算法实现类太多因为策略算法的多少取决于你的业务复杂度正是因为策略算法很多才体现出业务的复杂,才更需要用好策略模式。
