架构师_设计模式_行为模式之策略模式
反面例子:
一个商场收银系统初期做的时候只考虑简单的金额加减, 写在一个计算方法中, 某节假日突然需求扩展 增加一个满100-50活动 满200-100活动 满500-300
此时是不是只能在这一个计算方法中, 根据金额进行相应的if或者switch判断,然后进把金额返回给前端
正面例子:
使用策略模式:把折扣活动选择权让客户端去判断, 使得算法和客户端解耦,后面增加任何折扣活动都不会影响其他算法
解决了什么问题;
原先,我们要增加一个折扣算法,只能在一个总流程里面进行代码更改,增加很多的if判断
现在,现在我们增加一个折扣算法,只需要增加一个具体算法类,然后前端加一个选择框就可以了 扩展多方便,还能给具体算法类进行单元测试
using System; //为什么使用设计模式:对未来极有可能发生变化的问题预先用设计模式,已达到未来需求改造更简单,降低成本 namespace 策略模式 { //策略模式针对一组算法,将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换。 //策略模式使得算法可以在不影响到客户端的情况下发生变化。 //策略模式把行为和环境分开。环境类负责维持和查询行为类,各种算法在具体的策略类中提供。 //由于算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。 class Program { static void Main(string[] args) { //实现场景 Context context; Console.WriteLine("前端页面根据你的金额,选择了一个折扣活动传入concreteStrategyA"); context = new Context( new concreteStrategyA()); context.ContextInterface(); Console.WriteLine("计算完成"); } } /// <summary> /// 抽象策略类 /// 为Context定义了一系列可供重用的算法或者行为, 复杂的情况下 使得每个算法类都可以进行单元测试 /// </summary> abstract class Strategy { //算法方法 public abstract void AlgorithmInterface(); } //具体算法A 每个算法都是自己单独类,修改不会影响其他算法 class concreteStrategyA : Strategy { public override void AlgorithmInterface() { Console.WriteLine("搞活动,满5000-1000"); } } //具体算法B class concreteStrategyB : Strategy { public override void AlgorithmInterface() { Console.WriteLine("搞活动,满1W打9九折"); } } //具体算法C class concreteStrategyC : Strategy { public override void AlgorithmInterface() { Console.WriteLine("搞活动,满100-90"); } } //上下文 class Context { Strategy strategy; public Context(Strategy strategy) {//初始化的时候,传入具体的策略对象 this.strategy = strategy; } //根据具体的策略对象,调用其算法 public void ContextInterface() { strategy.AlgorithmInterface(); } } }
本文来自博客园,作者:12不懂3,转载请注明原文链接:https://www.cnblogs.com/LZXX/p/12837395.html