策略模式

实例场景：
1、一位父亲有三个儿子，在临终签前告诉他们死后会留下的东西，分别给他们每人送了一个箱子，A儿子打开箱子需要解决一个问题能够拿到的是一栋别墅，B儿子打开箱子需要解决一个问题能够拿到的是一辆豪车，C儿子打开箱子需要解决一个问题能够拿到的是一笔巨款，在这个场景中我们用到了策略模式，下面详细说明。
2、在java的集合框架中，我们有多钟排序算法，只要用户想要哪种排序，生成相应的排序类，然后传入到Collection的sort参数中，就能够实现相应的排序规则，这里面用到了我们的策略模式。
策略模式：
策略模式，又叫算法簇模式，就是定义了不同的算法族，并且之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
策略模式的好处在于你可以动态的改变对象的行为。

设计原则
设计原则是把一个类中经常改变或者将来可能改变的部分提取出来，作为一个接口（c++z中可以用虚类），然后在类中包含这个对象的实例，这样类的实例在运行时就可以随意调用实现了这个接口的类的行为。下面是一个例子。 策略模式属于对象行为型模式，主要针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。通常，策略模式适用于当一个应用程序需要实现一种特定的服务或者功能，而且该程序有多种实现方式时使用。
策略模式中有三个对象：
（1） 环境对象：该类中实现了对抽象策略中定义的接口或者抽象类的引用。
（2） 抽象策略对象：它可由接口或抽象类来实现。
（3） 具体策略对象：它封装了实现同不功能的不同算法。
利用策略模式构建应用程序，可以根据用户配置等内容，选择不同有算法来实现应用程序的功能。具体的选择有环境对象来完成。采用这种方式可以避免由于使用条件语句而带来的代码混乱，提高应用程序的灵活性与条理性。
代码实现场景：
模拟场景1：

package cn.com.strategy; //定义一个策略接口，这是父亲给三个儿子设计问题取得遗产的接口 public interface IStrategy { 	//打开箱子，每个问题都是一个算法 	public void execute(); }

package cn.com.strategy; //定义一个实现类，A儿子打开箱子，解决问题，得到一栋别墅 public class ImplA implements IStrategy { 	@Override 	public void execute() { 		System.out.println("解决问题，得到一栋别墅");  	}  }

package cn.com.strategy; //定义一个实现类，B儿子打开箱子，解决问题，得到一栋豪车 public class ImplB implements IStrategy { 	@Override 	public void execute() { 		System.out.println("解决问题，得到一辆豪车"); 	}  }

package cn.com.strategy; //定义一个实现类，C儿子打开箱子，解决问题，得到一笔巨款 public class ImplC implements IStrategy { 	@Override 	public void execute() { 		System.out.println("解决问题，得到一笔巨款");  	}  }

package cn.com.strategy; //定义一个环境对象，在场景中就像那个箱子 public class Environment { 	private IStrategy iStrategy; 	//两种方法为其赋值,构造和set、get 	public Environment(IStrategy iStrategy){ 		this.iStrategy=iStrategy; 	} 	 	public void execute(){ 		iStrategy.execute(); 	} 	 }

package cn.com.strategy; //测试类,看似代码一样，但是传入不同的实现类，得到不同结果 public class Test { 	public static void main(String[] args) { 		Environment e=new Environment(new ImplA()); 		e.execute();//A儿子打开箱子解决问题，得到一栋别墅 		e=new Environment(new ImplB()); 		e.execute();//B儿子打开箱子解决问题，得到一辆豪车 		e=new Environment(new ImplC()); 		e.execute();//C儿子打开箱子解决问题，得到一笔巨款 	}  }

输出结果将会是：
解决问题，得到一栋别墅

解决问题，得到一辆豪车 解决问题，得到一笔巨款  模拟场景2： package cn.com.strategy;  import java.util.List; //定义一个排序的策略接口 public interface SortStrategy<T> { 	public void sort(List<T> list);//执行排序算法 }

package cn.com.strategy;  import java.util.List;  //定义一个实现类，实现冒泡排序 public class SortBubble<T> implements SortStrategy<T> { 	@Override 	public void sort(List<T> list) { 		System.out.println("实现冒泡排序算法"); 	}  }

package cn.com.strategy;  import java.util.List;  //定义一个实现类，实现堆排序 public class SortHeap<T> implements SortStrategy<T> { 	@Override 	public void sort(List<T> list) { 		System.out.println("实现堆排序算法"); 	} }

package cn.com.strategy;  import java.util.List;  //定义一个实现类，实现快速排序 public class SortQuick<T> implements SortStrategy<T> { 	@Override 	public void sort(List<T> list) { 		System.out.println("实现快速排序算法"); 	}  }

package cn.com.strategy;  import java.util.List;  //定义一个环境对象，在场景中就是我们的算法使用者 public class Sorter { 	private SortStrategy iStrategy; 	//两种方法为其赋值,构造和set、get 	public SortStrategy getiStrategy() { 		return iStrategy; 	}  	public void setiStrategy(SortStrategy iStrategy) { 		this.iStrategy = iStrategy; 	} 	//传入相应的算法，对其进行排序 	public void sort(List list){ 		this.iStrategy.sort(list); 	} 	 }

package cn.com.strategy;  import java.util.ArrayList; import java.util.List;  //测试类,看似代码一样，但是传入不同的排序实现类，得到不同的排序结果 public class Test { 	public static void main(String[] args) { 		List list=new ArrayList(); 		list.add(2); 		list.add(3); 		list.add(1); 		Sorter sort=new Sorter(); 		SortBubble<Integer> sb=new SortBubble<Integer>(); 		sort.setiStrategy(sb);//实现冒泡排序 		sort.setiStrategy(new SortHeap<Integer>());//实现堆排序 		sort.setiStrategy(new SortQuick<Integer>());//实现快速排序 		 	}  }

输出相应的排序结果
在我们的集合框架中可以设计不同的Comparator来实现不同的比较方式，大大的提高了程序的扩展性，但值得说的类也要实现Comparable接口，只是在Comparable接口的实现方法中使用我们自己设置的排序策略，当然我们可以指定默认的排序算法，如上，这样如果有特殊需求时，在设置相应的排序算法，极大的提高了系统的灵活性。

策略模式优缺点
优点：
1、 简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
2、 避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。
3、 遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。
缺点：
1、 因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。
2、 在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。（这本身没有解除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由Context来承担，这就最大化的减轻了客户端的压力。）
简单工厂模式和策略模式区别（摘录，出处）
这两种模式的作用就是拥抱变化，减少耦合。在变化来临时争取做最小的改动来适应变化。这就要求我们把些“善变”的功能从客户端分离出来，形成一个个的功能类，然后根据多态特性，使得功能类变化的同时，客户端代码不发生变化。
简单工厂模式
简单工厂模式：有一个父类需要做一个运算（其中包含了不同种类的几种运算），将父类涉及此运算的方法都设成虚方法，然后父类派生一些子类，使得每一种不同的运算都对应一个子类。另外有一个工厂类，这个类一般只有一个方法（工厂的生成方法），这个方法的返回值是一个超类，在方法的内部，根据传入参数的不同，分别构造各个不同的子类的对象，并返回。客户端并不认识子类，客户端只认识超类和工厂类。每次客户端需要一中运算时，就把相应的参数传给工厂类，让工厂类构造出相应的子类，然后在客户端用父类接收（这里有一个多态的运用）。客户端很顺理成章地用父类的计算方法（其实这是一个虚方法，并且已经被子类特化过了，其实是调用子类的方法）计算出来结果。如果要增加功能时，你只要再从父类中派生相应功能的子类，然后修改下工厂类就OK了，对于客户端是透明的。
策略模式
策略模式：策略模式更直接了一点，没有用工厂类，而是直接把工厂类的生成方法的代码写到了客户端。客户端自己构造出了具有不同功能的子类（而且是用父类接收的，多态），省掉了工厂类。策略模式定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。这里的算法家族和简单工厂模式里的父类是同一个概念。当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为，将这些行为封装在一个个独立的策略子类中，可以在客户端中消除条件语句。
简单工厂模式+策略模式：为了将工厂方法的代码从客户端移出来，我们把这些代码搬到了父类的构造函数中，让父类在构造的时候，根据参数，自己实现工厂类的作用。这样做的好处就是，在客户端不用再认识工厂类了，客户端只要知道父类一个就OK，进一步隔离了变化，降低了耦合。
在基本的策略模式中，选择所用具体实现的职责由客户端对象成端，并转给客户端。这本身并没有减除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由父类承担，这就最大化地减轻了客户端的职责。
总结
策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。