博客
关于我
强烈建议你试试无所不能的chatGPT，快点击我
设计模式——策略模式
阅读量：632 次
发布时间：2019-03-14

本文共 4873 字，大约阅读时间需要 16 分钟。

模拟场景：

某某公司要求我们做一个商场收银系统，

提出需求：商场会不定时举办一系列的优惠活动，优惠方式暂定为：打折扣，满多少还多少（例如：满300还100）

 

初步场景分析：

看到这个需求，第一感觉就会潜意识的认为“这个太简单了”。

1.商场收银系统：定义为winform的应用程序

2.活动优惠的计算，判断一下就可以了。

 

初步代码实现：

 

[csharp]   
 
  1. /// <summary>  
  2.        /// 点击确定计算收费  
  3.        /// </summary>  
  4.        /// <param name="sender"></param>  
  5.        /// <param name="e"></param>  
  6.        private void btnOk_Click(object sender, EventArgs e)  
  7.        {  
  8.            int number = Convert.ToInt32(this.txtNumber.Text);  
  9.            double price = Convert.ToDouble(this.txtPrice.Text);  
  10.            double total = 0;  
  11.            switch (this.cbxType.SelectedItem.ToString())  
  12.            {  
  13.                case "正常收费":  
  14.                    total = number * price;  
  15.                    break;  
  16.                case "满300返100":  
  17.                    moneyCondition = 300;  
  18.                    moneyReturn = 100;  
  19.                    double money = Convert.ToDouble(txtPrice.Text) * Convert.ToInt32(txtNumber.Text);  
  20.                    if (money >= moneyCondition)  
  21.                    {  
  22.                        total = money - Math.Floor(money / moneyCondition) * moneyReturn;  
  23.                    }  
  24.                    break;  
  25.                case "打8折":  
  26.                    total = Convert.ToDouble(txtPrice.Text) * Convert.ToInt32(txtNumber.Text) * 0.8;  
  27.                    break;  
  28.            }  
  29.            this.lbxList.Items.Add("单价：" + txtPrice.Text + "数量：" + txtNumber.Text + " "  
  30.                + cbxType.SelectedItem.ToString() + "合计： " + total.ToString());  
  31.            this.lblResult.Text = total.ToString();  
  32.   
  33.        }  

好，现在我们来分析一下上面的实现：

咋一看，感觉没什么问题,可再细分析，问题就多了：

1：显示和逻辑紧密的联系在一起。

2：完全过程式的编程,没办法复用。

3：当新需求增加的时候，还需要修改这个条件分支，不符合开放封闭原则,过多的判断不利于维护。

经过以上分析，进行初步的修改：

先来看看结构图：

 

工厂类：

[csharp]   
 
  1. public class CashFactory  
  2.     {  
  3.         public static CashSuper createCashAccpet(string type)  
  4.         {  
  5.             CashSuper cs = null;  
  6.             switch (type)  
  7.             {  
  8.                 case "正常收费":  
  9.                     cs = new CashNormal();  
  10.                     break;  
  11.                 case "满300返100":  
  12.                     cs = new CashReturn("300","100");  
  13.                     break;  
  14.                 case "打8折":  
  15.                     cs = new CashRebate("0.8");  
  16.                     break;  
  17.             }  
  18.             return cs;  
  19.         }  
  20.     }  

运算父类：

[csharp]   
 
  1. /// <summary>  
  2.     /// 现金收取父类,算法的抽象类  
  3.     /// </summary>  
  4.     public abstract class CashSuper  
  5.     {  
  6.         /// <summary>  
  7.         /// 抽象方法：收取现金  
  8.         /// </summary>  
  9.         /// <param name="money">原价</param>  
  10.         /// <returns>当前价</returns>  
  11.         public abstract double acceptCash(double money);  
  12.     }  

折扣类：

[csharp]   
 
  1.  /// <summary>  
  2. /// 打折收费  
  3. /// </summary>  
  4. public class CashRebate:CashSuper  
  5. {  
  6.     private double moneyRebate = 1d;  
  7.   
  8.     public CashRebate(string money)  
  9.     {  
  10.         this.moneyRebate = double.Parse(money);  
  11.     }  
  12.   
  13.     //初始化时必需输入折扣率，如八折就是0.8  
  14.     public override double acceptCash(double money)  
  15.     {  
  16.         return money * moneyRebate;  
  17.     }  
  18. }  

返利类：

[csharp]   
 
  1. /// <summary>  
  2. /// 返利收费  
  3. /// </summary>  
  4. public class CashReturn:CashSuper  
  5. {  
  6.     private double moneyCondition = 0.0d;  
  7.     private double moneyReturn = 0.0d;  
  8.   
  9.     /// <summary>  
  10.     /// 初始化时必须要输入返利条件和返利值，比如满300返100，则moneyCondition为300，moneyReturn为100  
  11.     /// </summary>  
  12.     /// <param name="moneyCondition"></param>  
  13.     /// <param name="moneyReturn"></param>  
  14.     public CashReturn(string moneyCondition,string moneyReturn)  
  15.     {  
  16.         this.moneyCondition = double.Parse(moneyCondition);  
  17.         this.moneyReturn = double.Parse(moneyReturn);  
  18.     }  
  19.   
  20.     public override double acceptCash(double money)  
  21.     {  
  22.         double result = money;  
  23.         //若大于返利条件，则需要减去返利值  
  24.         if (money>=moneyCondition)  
  25.         {  
  26.             result = money-Math.Floor(money/moneyCondition)*moneyReturn;  
  27.         }  
  28.         return result;  
  29.     }  
  30. }  

正常收费类：

[csharp]   
 
  1.  /// <summary>  
  2. /// 正常收费  
  3. /// </summary>  
  4. public class CashNormal:CashSuper  
  5. {  
  6.     public override double acceptCash(double money)  
  7.     {  
  8.         return money;  
  9.     }  
  10. }  

好的,经过完善之后我们的代码已经出来了,下面我们再来细细分析一下这代码：

代码使用了简单工厂模式来解决了对象的创建,通过抽象实现了业务逻辑的分离,在维护性上也得到了改善。

那么这代码就没有问题了吗？答案是：有

现在假设我们要为商场添加一种优惠活动，满100积分送10点，以后积分达到一定值就可以领取奖品。

我们该怎么去做呢：现在有了工厂，我们只需要添加一个积分的类，

让它继承运算父类(CashSuper),在再工厂条件分支里添加一个满100积分送10点的条件分支，界面再稍稍修改就可以了。

这么想虽然是可以解决问题，但是工厂里包含了所有的收费方式，商场是可能经常性的更改打折额度，添加新的优惠方式，

如果是这样的话，我们每次维护或扩展收费方式都要去改动这个工厂，这样做就不得不让代码重新编译部署，这样的处理方式是很糟糕的。

那么我们该如何去做呢？现在我们就进入正题：其实商场的促销活动，打折活动，返利活动都是一些算法，而算法本身只是一种策略，

最重要的是这些算法是随时都可能互相替换的，这就是变化点，而封装变化点是我们面向对象的一种很重要的思维方式。

 

 

我们先来看看策略模式的结构图：

Strategy类，定义所有支持的算法和公共接口：

ConcreteStrategy封装了具体的算法或行为，继承于Strategy:

Context,用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用：

客户端的实现：

 

下面我们就用策略模式来改善一下我们的代码：

代码结构图：

现有的代码没有CashContext，我们就添加一个CashContext的类：

其他的类不变，客户端实现：

经过策略模式完善的代码已经实现，下面我们再来分析一下我们的代码：

现在问题又来了，算法的判断又回到客户端里来了，我们该如何去解决这个问题呢？

其实我们可以让策略模式与简单工厂模式相结合，下面我们来看看怎么个实现法：

在CashContext里进行对象的构造：

客户端实现：

 

经过进一步的优化，我们的代码已经比较的优化了，但是一个很明显的问题也显示出来了，就是switch的条件判断分支，

当我们需要添加一种算法的时候，我们还是需要修改CashContext里的switch算法，这样的代码还是让人非常的不爽，哪还有什么方法呢？

我们可以使用反射来改善现有的代码(反射的具体原理与实现将在不久写出)：

switch算法的条件判断分支我们抽取出来，用一个xml文件进行记录：

接下来我们只需要在加载事件中将xml的信息读取出来绑定就可以了：

由于我们的switch已经转移到xml中了，那么我们的CashContext类就可以简化成：

我们的具体算法实现类不变，现在我们最主要就是通过反射去实例化不同的算法对象：

 

 总结：

代码经过多次的修改，可维护性，代耦合高内聚的特性已经展现出来了，现在我们再来分析一下上面的代码吧，上面我们通过反射去除了switch分支，

有效的把耦合降到最低，但是这样做也是有一点点代价的，反射会比较耗一点性能，所以我们做程序的时候要具体问题具体分析。

通过上面的代码我们来分析一下策略模式吧：

策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。

 

应用场景：
1、 多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。
2、 需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。
3、 对客户隐藏具体策略(算法)的实现细节，彼此完全独立。
 

优点：

1、策略模式简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试，每个算法可以保证它没有错误，修改其中任一个时也不会影响其他的算法。

2、策略模式封装了变化，策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，

只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

3、策略模式有利于程序的高内聚、低偶合性，使得程序更加的灵活。

 

缺点：

基本策略模式中所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象，

这本身并没有解除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由Context来承担，这就是最大化地减轻了客户端的职责。

 

转自：http://blog.csdn.net/shiyuan17/article/details/9056637

你可能感兴趣的文章
喝酒易醉，品茶养心，人生如梦，品茶悟道，何以解忧？唯有杜康！-- 愿君每日到此一游！
当前时间: 2025-03-14 08:01:42   当前IP: 3.21.55.224   联系邮箱:javaeecc@qq.com     Copyright © 2020 - 2022 baihongyu.com 京ICP备2021015314号-2
强烈建议你试试无所不能的CHAT-GPT，快点击我
强烈建议你试试无所不能的CHAT-GPT，快点击我