以下内容来自HeadFIrst设计模式一书和http://www.cnblogs.com/xrq730/p/4906313.html的博文，作为自己的学习笔记总结如下。
HeadFirst设计模式一书在开篇就提出了三条设计的原则：
1.找出应用中可能需要变化之处，将它们独立出来，不要和那些需要变化的代码混在一起。
2.针对接口编程，而不是针对实现编程。
3.多用组合，少用继承。
策略模式------定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
以书中的鸭子游戏SimUDuck为例进行分析：
鸭子游戏SimUDuck中有各种鸭子，有游泳和呱呱叫的功能，最初的超类如下图所示：
后来想要为部分鸭子添加会飞的功能，程序员Joe直接在父类上添加了fly()，导致超级父类变成下图：
这就导致所有的鸭子都具备的飞的功能，这显然是不符合常理的。并且同理，并不是所有的鸭子都有Quack的功能，比如橡皮鸭。于是程序员Joey将quack()和fly()两个方法都抽离出来，实现成两个接口Quackable和Flyable，只要是会飞的鸭子就实现Quackable接口即可，会飞实现Flyable接口即可。
但是这导致了代码无法复用的问题，每个鸭子子类，只要是会飞就必须自己实现Flyable接口中的fly()一次，如果有100个会飞的鸭子子类，这个fly方法就必须同样的书写100次，这显然极不合理。
这时，应用以上三条设计原则：
1.将变化的和不变的进行分离------Duck类仍然是所有鸭子的超类，但是每个鸭子子类的飞行和呱呱叫的行为是不同的，需要将这两个行为取出，抽象成行为接口FlyBehavior和QuackBehavior；
2.针对接口编程，而不是针对实现进行编程----------将鸭子的行为放在专门的行为类中，这些行为类需要实现相应的行为接口，而不是由Duck类实现行为接口。这样的设计可以使这些行为类被其他对象复用，比如天鹅类也可以飞，大雁类也可以飞，青蛙也可以呱呱叫，这使得这些行为与鸭子类无关。
3. 多用组合，少用继承-------------每一个鸭子子类都有一个FlyBehavior和QuackBehavior 接口的实例化对象，让鸭子将行为由这两个对象进行处理。 不同于以往的做法，我们可以看到鸭子的行为不是继承而来，而是和行为接口的实例化对象组合而来。具备这个行为的鸭子对象和行为的实例化对象是has-a的关系。
实现如下：
父类：
package Test; public abstract class Duck { QuackBehavior quackBehavior;//注意，持有的对象类型是接口类型 FlyBehavior flyBehavior; public void swim(){ System.out.println("I can swim"); } public abstract void display(); public void performQuack(){//调用相应的行为方法 quackBehavior.quack(); } public void perfromFly(){ flyBehavior.fly(); } public void setQuackBehavior(QuackBehavior quackBehavior){//可以动态的对行为进行设置 this.quackBehavior=quackBehavior; } public void setFlyBehavior(FlyBehavior flyBehavior) { this.flyBehavior = flyBehavior; } }
飞行接口
package Test; public interface FlyBehavior { public void fly(); }
嘎嘎叫接口
package Test; public interface QuackBehavior { public void quack(); }
具体行为实现：
package Test; public class FlyWithWings implements FlyBehavior { @Override public void fly() { System.out.println("我有一双隐形的翅膀带我飞翔"); } }
package Test; public class FlyNoWay implements FlyBehavior { @Override public void fly() { System.out.println("I can't fly"); } }
package Test; public class Quack implements QuackBehavior { @Override public void quack() { System.out.println("嘎嘎嘎"); } }
测试类：
package Test; public class MiniDuckSimulator { public static void main(String[] args){ Duck mallard=new MallardDuck(); mallard.display(); mallard.performQuack(); mallard.perfromFly(); mallard.setFlyBehavior(new FlyNoWay()); mallard.perfromFly(); } }
输出：
策略模式的总结
以下内容转自：http://www.cnblogs.com/xrq730/p/4906313.html
策略模式
策略模式的用意是针对一组算法，将每一个算法封装到具有共同接口的独立类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。
策略模式的结构
策略模式是对算法的包装，是把使用算法的责任和算法本身分开。策略模式通常是把一系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。
策略模式涉及到三个角色：
1、环境角色
持有一个策略Strategy的引用
2、抽象策略角色
这是一个抽象角色，通常由一个接口或抽象类实现，此角色给出所有具体策略类所需的接口
3、具体策略角色
包装了相关算法或行为
策略模式示例
有一个抽象的策略接口：
public interface Strategy
{
public void useStrategy();
}
实现两种具体的策略：
public class StrategyA implements Strategy
{
public void useStrategy()
{
System.out.println("StrategyA.useStrategy()");
}
}
public class StrategyB implements Strategy
{
public void useStrategy()
{
System.out.println("StrategyB.useStrategy()");
}
}
某个类持有策略的引用：
public class Context
{
private Strategy strategy;
public Context(Strategy strategy)
{
this.strategy = strategy;
}
public void strategyMethod()
{
strategy.useStrategy();
}
}
调用这个类的地方可以自行决定使用哪种策略：
public class TestMain
{
public static void main(String[] args)
{
Strategy strategyA = new StrategyA();
Strategy strategyB = new StrategyB();
Context context = new Context(strategyA);
context.strategyMethod();
context = new Context(strategyB);
context.strategyMethod();
}
}
策略模式的使用场景
1、购物系统
举一个实际例子吧。假如有一个购物系统，在用户付款的时候，会产生很多场景，根据用户的不同情况算出不同用户要付款的金额，这时候最直观的一种做法是：
在付款的里面写N多的if...else if...else，判断用户的场景，根据场景计算用户付款金额。
这种设计明显违反了开闭原则。开闭原则的"闭"，指的是对修改关闭，但是这里假如算法又多了几种，那么必须再次修改这个付款的类。
这时候就可以使用策略模式。在付款的类里面持有一个付款接口的引用，每次根据不同场景传入一个具体的策略就好了。比如A类中要使用S0算法，就传入一个S0策略；B类中要使用S1算法，就传入一个S1算法。不需要把判断都放在付款的类中，代码的可读性、可维护性也更高了。付款这个类甚至可以直接生成一个.class文件放在一个jar包里面供调用。
2、使得代码更优雅、更易维护
假如你的代码中某处有一个打分系统，你为这个打分系统写了一段非常长的逻辑，某天，产品部门的同事找你，给我换一段打分逻辑，此时，有两种做法：
（1）把原有的打分逻辑删除，但这么做一个缺点是是看不到以前的打分算法了，另一个缺点是如果以后打分算法要换回来就找不到代码，虽然SVN和GIT这种版本管理工具都有历史提交记录的功能，但还是显得麻烦
（2）把原有的打分逻辑注释，但这么做的最大缺点是代码中有大量的注释，尤其在策略逻辑非常长的时候，这就导致了代码的可读性非常差
此时，就可以使用策略模式，将打分逻辑抽象为一种策略，换打分策略，新增一个策略的实现类，最后再让代码中传入新的策略实现类即可。
策略模式在Java中的应用及解读
策略模式在Java中的应用，这个太明显了，因为Comparator这个接口简直就是为策略模式而生的。Comparable和Comparator的区别一文中，详细讲了Comparator的使用。比方说Collections里面有一个sort方法，因为集合里面的元素有可能是复合对象，复合对象并不像基本数据类型，可以根据大小排序，复合对象怎么排序呢？基于这个问题考虑，Java要求如果定义的复合对象要有排序的功能，就自行实现Comparable接口或Comparator接口，看一下sort带Comparator的重载方法：
1 public static <T> void sort(List<T> list, Comparator<? super T> c) {
2 Object[] a = list.toArray();
3 Arrays.sort(a, (Comparator)c);
4 ListIterator i = list.listIterator();
5 for (int j=0; j<a.length; j++) {
6 i.next();
7 i.set(a[j]);
8 }
9 }
跟一下第3行：
1 public static <T> void sort(T[] a, Comparator<? super T> c) {
2 T[] aux = (T[])a.clone();
3 if (c==null)
4 mergeSort(aux, a, 0, a.length, 0);
5 else
6 mergeSort(aux, a, 0, a.length, 0, c);
7 }
传入的c不为null，跟一下第6行的mergeSort：
1 private static void mergeSort(Object[] src,
2 Object[] dest,
3 int low, int high, int off,
4 Comparator c) {
5 int length = high - low;
6
7 // Insertion sort on smallest arrays
8 if (length < INSERTIONSORT_THRESHOLD) {
9 for (int i=low; i<high; i++)
10 for (int j=i; j>low && c.compare(dest[j-1], dest[j])>0; j--)
11 swap(dest, j, j-1);
12 return;
13 }
14
15 // Recursively sort halves of dest into src
16 int destLow = low;
17 int destHigh = high;
18 low += off;
19 high += off;
20 int mid = (low + high) >>> 1;
21 mergeSort(dest, src, low, mid, -off, c);
22 mergeSort(dest, src, mid, high, -off, c);
23
24 // If list is already sorted, just copy from src to dest. This is an
25 // optimization that results in faster sorts for nearly ordered lists.
26 if (c.compare(src[mid-1], src[mid]) <= 0) {
27 System.arraycopy(src, low, dest, destLow, length);
28 return;
29 }
30
31 // Merge sorted halves (now in src) into dest
32 for(int i = destLow, p = low, q = mid; i < destHigh; i++) {
33 if (q >= high || p < mid && c.compare(src[p], src[q]) <= 0)
34 dest[i] = src[p++];
35 else
36 dest[i] = src[q++];
37 }
38 }
第10行，根据Comparator接口实现类的compare方法的返回结果决定是否要swap（交换）。
这就是策略模式，我们可以给Collections的sort方法传入不同的Comparator的实现类作为不同的比较策略。不同的比较策略，对同一个集合，可能会产生不同的排序结果。
认识策略模式
应当明白，策略模式的重心不是如何实现算法（就如同工厂模式的重心不是工厂中如何产生具体子类一样），而是如何组织、调用这些算法，从而让程序结构更灵活，具有更好的维护性和扩展性。 软件开发在完成后的维护时间要比开发时间多的多，因为可能客户的需求会有变化，所以我们应该致力于提高可维护性和可扩展性上。策略模式降低了程序之间的耦合度，使得程序的维护更加容易。
策略模式有一个很大的特点就是各策略算法的平等性。对于一系列具体的策略算法，大家的地位是完全一样的，正因为这个平等性，各个算法之间才可以相互替换。
运行期间，每一个时刻只能使用一个具体的策略实现对象，虽然可以动态地在不同的策略中实现切换。
策略模式的优缺点
优点
1、避免了多重条件if...else if...else语句，多重条件语句并不容易维护
2、策略模式提供了管理相关算法簇的办法，恰当使用继承可以把公共代码移到父类，从而避免了代码重复
缺点
1、客户端必须知道所有的策略类，并自行决定使用 哪一个策略，这意味着客户端必须理解这些算法的区别，以便选择恰当的算法
2、如果备选策略很多，对象的数据会很多
另一个比较好的实例是：转自https://www.cnblogs.com/wuyudong/p/5924223.html
举个例子，计算公交车和地铁运行指定路程后所需的票价
package com.wuyudong.strategy.normal;
public class PriceCalculator {
// 公交车类型
private static final int BUS = 1;
// 地铁类型
private static final int SUBWAY = 2;
public static void main(String[] args) {
PriceCalculator calculator = new PriceCalculator();
System.out.println("坐10公里的公交车的票价为："
+ calculator.calculatePrice(10, BUS));
System.out.println("坐10公里的地铁的票价为："
+ calculator.calculatePrice(10, SUBWAY));
}
//计算公交价格
private int busPrice(int km) {
int extraTotal = km - 10;
int extraFactor = extraTotal / 5;
int fraction = extraTotal % 5;
int price = 1 + extraFactor * 1;
return fraction > 0 ? ++price : price;
}
//计算地铁价格
private int subwayPrice(int km) {
if (km <= 6) {
return 3;
} else if (km > 6 && km < 12) {
return 4;
} else if (km < 22 && km > 12) {
return 5;
} else if (km < 32 && km > 22) {
return 6;
}
return 7;
}
//根据类型来计算相应的价格
private int calculatePrice(int km, int type) {
if (type == BUS) {
return busPrice(km);
} else {
return subwayPrice(km);
}
}
}
如果再添加一种出租车的价格计算，添加相应的代码：
public class PriceCalculator {
// 公交车类型
private static final int BUS = 1;
// 地铁类型
private static final int SUBWAY = 2;
// 出租车类型
private static final int TAXI = 3;
public static void main(String[] args) {
PriceCalculator calculator = new PriceCalculator();
System.out.println("坐10公里的公交车的票价为："
+ calculator.calculatePrice(10, BUS));
System.out.println("坐10公里的地铁的票价为："
+ calculator.calculatePrice(10, SUBWAY));
}
// 计算出租车价格
private int taxiprice(int km) {
return km * 2;
}
// 根据类型来计算相应的价格
private int calculatePrice(int km, int type) {
if (type == BUS) {
return busPrice(km);
} else if (type == SUBWAY) {
return subwayPrice(km);
} else {
return taxiprice(km);
}
}
}
可见上面的代码耦合性较高，每当增加新的交通工具类型的时候，需要不断的修改大量的代码，这里使用策略模式重构：
首先定义一个抽象的价格计算接口：
//计算接口
public interface CalculateStrategy {
int calculatePrice(int km);
}
每一种出行方式都定义一个独立的计算策略类：
公交车计算策略
public class BusStrategy implements CalculateStrategy {
public int calculatePrice(int km) {
int extraTotal = km - 10;
int extraFactor = extraTotal / 5;
int fraction = extraTotal % 5;
int price = 1 + extraFactor * 1;
return fraction > 0 ? ++price : price;
}
}
地铁计算策略
public class SubwayStrategy implements CalculateStrategy {
public int calculatePrice(int km) {
if (km <= 6) {
return 3;
} else if (km > 6 && km < 12) {
return 4;
} else if (km < 22 && km > 12) {
return 5;
} else if (km < 32 && km > 22) {
return 6;
}
return 7;
}
}
再创建一个扮演Context的角色，代码如下：
public class TranficCalculator {
CalculateStrategy mStrategy;
public static void main(String[] args) {
TranficCalculator calculator = new TranficCalculator();
//设置计算策略
calculator.setStrategy(new BusStrategy());
//计算价格
System.out.println("公交车乘10公里的价格：" + calculator.calculatePrice(10));
}
public void setStrategy(CalculateStrategy mStrategy) {
this.mStrategy = mStrategy;
}
public int calculatePrice(int km) {
return mStrategy.calculatePrice(km);
}
}
这样即使需要添加出租车的价格计算，只需要简单的新建一个类，让其继承自CalculateStrategy接口并实现其中的方法即可。