【大话设计模式】——策略模式

一、开篇

　　上篇文章【大话设计模式】——简单工厂模式告诉了我们一个网吧收费工厂对象如何创建收费形式（白天收费、夜间收费）的实例。简单工厂代码中有很多 case分支语句 ,如果我们还想填加收费的形式（比如会员收费啊，通宵收费啊），就需要改动工厂代码，每次维护和扩展都要花费很多时间，另外改动很容易造成纰漏（比如之前的白天收费形式，很可能因为改动从多收钱或者少收钱），所以简单工厂模式很不安全。所以我们要把经常变化的代码抽象出来，做到业务逻辑和界面逻辑分开，只有这样才能更加容易做到维护和扩展。

　　发现问题，解决问题，人类就这样一点一滴的进步着。

　　发现了简单工厂的不好，策略模式就诞生啦，人类真的是很睿智！（呱唧呱唧）

　　下面大家熟悉一下策略模式的定义：

　　策略模式（Strategy）:它定义了算法家族，分别封装起来，让她们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。

 

二、UML图

Context（环境类）：需要使用ConcreteStrategy的具体算法，维护一个对Strategy对象的引用，负责跟Strategy之间的交互和数据传递。

Strategy（抽象策略类）：定义所有支持的算法的公共接口。Context使用这个接口来调用ConcreteStrategy算法。

ConcreteStrategy（具体策略类）：封装了具体的算法和行为，继承与Strategy.

图中含有两种关系，聚合和继承。

 

三、实例解析

比如我们填饱肚子的方式，有几个策略可以考虑：吃水果、吃蔬菜、吃馒头。首先定义一个抽象类吃，然后让吃的形式：吃水果，吃蔬菜，吃馒头继承这个抽象吃类，再声明一个Context类，用来配置吃的方法，维护一个对Strategy对象的引用。

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication7
{
    class Program
    {
        static void Main(string[] args)//客户端代码
        {
            Context context;
            context = new Context(new EatingFruit());//实例化不同的策略，调用的时候获得的结果就不同。
            context.ContextInterface();

            context = new Context(new EatingVegetables());
            context.ContextInterface();

            context = new Context(new EatingSteamBread());
            context.ContextInterface();
        }
    }


    abstract class EatStrategy//抽象吃法类
    {
        public abstract void Eat();
    }

    class EatingFruit:EatStrategy //具体吃法吃苹果 
    {
        public override void Eat()
        {
            Console .WriteLine ("饿了吃苹果");
        }
    }
    class EatingVegetables : EatStrategy//具体吃法吃蔬菜
    {
        public override void Eat()
        {
            Console .WriteLine ("吃蔬菜也不饿");
        }
    }
    class EatingSteamBread : EatStrategy//具体吃法吃馒头
    {
        public override void Eat()
        {
            Console .WriteLine ("吃馒头也不错");
        }
    }

    class Context//写策略环境类
    {
        EatStrategy eatstrategy;
        public Context(EatStrategy eatstrategy)//初始化时，传入具体的策略对象
        {
            this.eatstrategy = eatstrategy;
        }
        //上下文接口
        public void ContextInterface()//根据具体的策略对象，调用其算法的方法
        {
            eatstrategy.Eat();
        }
    }
    
}

 

 

 

 

 

四、总结

策略模式的优点：

1）所有的算法完成相同的工作，只是实现不同，它以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。

个人理解：不管是吃水果还是吃蔬菜，异或是吃馒头，都是为了填饱肚子，虽然形式不同，如果有的人挑食吃饭一定要吃菜加馒头才肯吃，那如果没有卖馒头的，你就要减肥啦~

2）策略模式Strategy类层次为Context定义了一系列的可供重用的算法和行为。继承有助于析取出这些算法中的公共功能。

个人理解：把东西分类放置，使用的时候就更加容易找到。

3）简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

个人理解：有单独的类，就更容易满足单一职责原则，这样测试一个功能，数据如果不对，直接就能划分出范围。比如值日分为扫地和擦桌子，安排小明拖地，小红擦桌子。如果值完日了，地面还脏，那肯定就是小明干的不好呗（当然排除搞破坏的可能）。但是如果你让两个人干活，又没有分配任务，那好了，挨罚就两个人一起做个伴吧！

4）算法封装在单独的类中，可以消除条件语句，为客户端减轻了压力。

个人理解：领导者如果负责一个很庞大的工程的话，那些琐事会让他局限于细节，而失去了把控能力。

 

缺点：

1）客户端必须知道所有的策略类，并自行决定使用哪个策略类。

2）Strategy和Context之间存在通信开销

3）如果具体策略过多，会产生很多的策略类，增加了维护的难度。

  

代码即人生啊~