策略模式

首先推荐本书，HeadFrist……

我打算用自己的理解来阐述一下设计模式~当然由于还是初级程序猿，可能很多是理解不到位的，只供入门的童鞋参考参考，轻喷！！

主要从对比的角度分析设计模式，看看用了设计模式到底好在哪？

策略模式（官方定义）：定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。

先不看这些条条框框的定义吧~举个例子来分析：

eg 游戏角色设计（我这里只是针对策略模式来举个简单小例子。。）

首先每个角色肯定都能移动吧，所以这种属性可以把它放在role里面（role是所有角色继承的基类），相同的属性嘛，放在父类大家复用它，于是每个角色都能走路

嗯，那么就写了个role基类，里面有move方法，一共5中角色都继承它，这时候每个角色都有一个move（）{……走路}

这时候，你老板说，有个新的需求，我们要加入“龙”这个角色，龙的移动方式是飞行，于是你在龙这个角色覆盖了父类的移动方法，重写move（）{……内容是飞行}

几天过去了，老板又提出“鸟”这个角色，它也是飞的。那么问题来了，你是不是还是继承role这个父类，然后再覆盖role类的移动方法变成飞行~（ps：role必须继承，因为有很多共同的属性和动作，例如：例如角色名这个属性肯定大家都必须有（属性），眨眼睛这个动作（方法））

问题1：移动动作从一开始单纯的走路，到后面有飞行，当新的需求进来，是不是每次加入一个新的动作，都必须覆盖父类的方法，重写一下。那么，父类role的move方法已经达不到公用的效果了。原因是：move方法是变化的

问题2：有的人会说，既然是变化的，就不要写在父类里，让每个子类自己实现各自的移动动作，那么如果每个子类都写一遍move方法，那么会出现走路的角色全部都写一遍move(){……走路}，飞行亦然。造成了代码高度重复。假设走路的姿势要变化，那么是不是所有的代码都要一一改过去~简单的例子都这么可怕！！

设计原则：找出应用中可能需要变化之处，把它独立出来，不要和那些不会变化的代码混在一块

设计原则：针对接口编程，而不是针对实现编程

设计原则：多用组合少用继承

解决办法：

将move这个行为提取出来，做成一个接口 interface Move{   public void move();}

设计一个走路的类叫 class Walk implements Move{ public void move() {.....走路}} 

设计一个飞行的类叫 class Fly implements Move{ public void move() {.....飞行}} 

角色的move统一的代码为

private Move move = null;

move() {

if(move == null) {

move = new Walk();//飞行的就是new Fly();

} 

move.move();

}//感受到好处了没，当然还可以提供setMove的方法，还能在运行期改变行为呢，比如说run~

这样设计的好处就是，将变化的move方法提取出来，当需要添加动作时，只需再写一个实现类，比如jump implements move

好处就是：扩展方便，重复最小化，维护方便（只需修改功能类）,提供setter方法，还可在运行期改变行为。

再来回头看看策略模式~

定义一个算法簇，分别封装起来-----------就是我们的move算法，走路的，飞行的，跑步的

让它们之间可以相互替换-------------因为他们都是接口move的实现类，具有相同的行为，因此他们是可以相互替换的。比如你想让走路变成跑步，只需setMove()

总结：使用策略模式的关键点，就是某个动作属于同一个行为，但是行为方式是变化的。