编这个策略模式的故事真的不好想，他和前面的桥接模式很类似，虽然桥接是结构模式，而策略是行为模式。
这次的故事真的不容易编啊，我们来看下一个我们变成遇到的情况吧。
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类图，是不是很一样。
当然我也很想说就是右边那个一样，一个抽象类比很多人基础而已。