作者：某人_Valar
如需转载请保留原文链接；
设计模式的3大类：
- 创建型模式（5种）建造者模式，单例模式，工厂方法模式，抽象工厂模式，原型模式。
- 结构性模式（7种）适配器模式，装饰模式，代理模式，外观模式，桥接模式，组合模式，享元模式。
- 行为型模式（11种）策略模式，模板方法模式，观察者模式，迭代器模式，责任链模式，命令模式，备忘录模式，状态模式，访问者模式，中介者模式，解释器模式。
1. 什么是策略模式
策略模式是行为型模式中的一种。
举个例子
有一个国王类，其具有打斗（fight）的方法，但是他需要根据情况的不同来选择不同的打斗方式，有时候用弓箭，有时候用匕首。
另一种情况是一个父类（比如，人物类）下有多个子类（骑士，国王），而这些子类都有一个打斗(fight)的方法，而在打斗中，大家都可以选择使用弓箭或者匕首。
如果都使用if-else的话，就会使用代码变的臃肿，而且难以复用。
那我们就可以根据不同的情况，将打斗的方式封装成不同的策略，将策略与它的使用对象分离开来。
定义：策略模式定义了算法（算法代表人物打斗的方式）族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。(《Head First设计模式》一书中的定义)
2. 策略模式的实现
（1）先定义一个策略接口
接口中有一个使用武器的方法
public interface WeaponBehavior {
public void useWeapon();
}
（2）具体策略接口的实现
分别定义2个策略来实现此接口，代表不同的打斗方法
public class KnifeBehavior implements WeaponBehavior {
@Override
public void useWeapon() {
System.out.println("使用匕首打斗");
}
}
public class BowAndArrowBehavior implements WeaponBehavior {
@Override
public void useWeapon() {
System.out.println("使用弓箭打斗");
}
}
（3）一个抽象的人物类
人物类“有一个”WeaponBehavior ，好将打斗方式交给WeaponBehavior 去处理，我们还可以使用setWeaponBehavior方法随时改变打斗方式。
这是将两个类结合起来使用。这种写法与“继承”的不同之处在于，人物的打方式不是继承来的，而是和适当的行为对象“组合”来的。
多用组合，少用继承是一个重要的设计原则。
public abstract class People {
WeaponBehavior weaponBehavior;
public void fight(){
weaponBehavior.useWeapon();
}
public void setWeaponBehavior(WeaponBehavior wb){
weaponBehavior = wb;
}
}
（4）国王与骑士类的创建
继承一下People就行了
public class King extends People {
}
public class Knight extends People {
}
（5）写一个测试
public class Test {
public static void main(String[] args){
People king1 = new King();
//国王1想使用匕首
king1.setWeaponBehavior(new KnifeBehavior());
king1.fight();
//国王1想换成弓箭
king1.setWeaponBehavior(new BowAndArrowBehavior());
king1.fight();
People knight1 = new Knight();
//骑士1使用弓箭
knight1.setWeaponBehavior(new BowAndArrowBehavior());
knight1.fight();
}
}
运行结果：
3. 使用策略模式的场景以及优缺点
对于面向对象设计的开发者，对策略模式应该比较熟悉，即使之前没有听说过，也可能已经使用过，因为它实质上就是面向对象中的继承和多态。
使用场景：
- 几个类的主要逻辑相同，只在部分逻辑的算法或行为上有区别
- 有几种相似的行为（或者说算法），客户端动态地决定要使用哪一种
- 对客户隐藏具体策略（算法）的实现细节
优点：
- 易于扩展，如果需要新增加一个策略，在原有代码的基础上，只需要实现接口即可
- 避免了使用多重条件，策略模式可以减少条件语句的使用，使得代码更容易维护。
缺点：
- 所有的策略都需要暴露除去，由客户端决定使用哪一个 。因此，客户端应该知道有什么策略，并且了解各种策略之间的区别。这就有悖于迪米特法则。
迪米特法则（Law of Demeter）又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
- 当策略类过多时，维护每一个策略类都会带来额外的开销。一般来说，策略类的数量不超过4个。
