设计模式系列7---金点子多多的策略模式

编这个策略模式的故事真的不好想，他和前面的桥接模式很类似，虽然桥接是结构模式，而策略是行为模式。

这次的故事真的不容易编啊，我们来看下一个我们变成遇到的情况吧。

 public class SortHelper{

    public static final int SORT_HEAP=0;
    public static final int SORT_BIN=1;
    public static final int SORT_SHELL=2;

    public void sort(int type){
        if(type==SORT_HEAP){
            HeapSort();
        }else if(type==SORT_BIN){
            BinSort();
        }else if(type==SORT_SHELL){
            ShellSort();
        }
    }

    public void HeapSort(){
        System.out.println("this is heap sort");

    }

    public void BinSort(){
        System.out.println("this is heap sort");

    }
    public void ShellSort(){
        System.out.println("this is shell sort");

    }
}

在我们的这个排序小助手类，我们根据不同的算法来选择不同的实现。但这个有一些问题，如果我们以后加了新的方法怎么办？
一种方法淡然是直接简单的修改，加多了else if，然后加多新的方法，但这不太像ocp原则啊，我们对修改尽量封闭的。而且当条件多了的时候，整个就恨臃肿，不容易维护了。

为此我们需要一些调整，这时候策略模式登场

代码实现

我们抽象出基本的算法内容

public abstract class SortMethond {

    abstract void sort();
}

接着我们去继承他，然后分别实现我们的算法。

public class QuickSortMethond extends SortMethond {

    @Override
    void sort() {
        System.out.println("this is quick sort");
    }
}

public class BinSortMethond extends SortMethond {

    @Override
    void sort() {
        System.out.println("this is binary sort");
    }
}

public class HeapSortMethond extends SortMethond {

    @Override
    void sort() {
        System.out.println("this is heap sort");
    }
}

有了上面这些基础，我们是时候做出些改变了。

public class SortHelper{


    private SortMethond sortMethong;

    public void setSortMethong(SortMethond sortMethong){
        this.sortMethong = sortMethong;
    }

    public void sort(){
        sortMethong.sort();
    }
｝

我们看到，我们改造后的小助手瘦身了不少啊！
从此我们的使用就变成这样了

    public static void main(String[] args) {
        QuickSortMethond quickSortMethond=new QuickSortMethond();
        SortHelper sortHelper=new SortHelper(quickSortMethond);
        sortHelper.sort();
    }

我们的使用就像上面这样啦。

好了，基本的流程介绍完了。

后记

过年的第一天，出去走了一天，晚上回来还饭局喝了点酒，现在一片混乱的头脑写完这篇文章。真不容易。

目前写了这么久，对于策略的使用还是挺少的。
现在还记得的是关于轨迹数据的一些处理的算法的封装的时候用到。

另外这个策略提供了方法的扩展灵活，不过有一个没变的就是选择，
现在我的方法是把判断条件从方法的里面挪到了外面，实质是没有改变的。

而且带来的另外一个重要问题就是，我们还需要去熟悉各个不同的算法，从而作出选择，因此建议当这些不同的行为和客户相关的行为时，才采用。而且真的为了灵活扩张性，带来了很多个具体的类。

他和我们的策略感觉还是挺像的，看下它们的uml图。
我们看下这个桥接的图：

下面这张是我们的策略的UML类图，是不是很一样。

当然我也很想说就是右边那个一样，一个抽象类比很多人基础而已。