再回想一下设计模式—

再回想一下设计模式——策略模式

在设计模式了解。这份报告既柔软测试审查和改进。

软测试必须通过java学习设计模式，尽管以往的研究C#，但设计模式的思想是一样的。

话不多说直奔主题。以下先了解一下什么事策略模式。

策略模式定义了算法家族，分别封装起来，让它们之间能够互相转换，此模式让算法的变化不会影响到使用算法的客户。

举个样例：

如今有一个鸭子父类，我们须要它的之类有绿头鸭、红头鸭。仅仅须要在父类里面写一个虚方法display然后让子类去重写，绿头鸭的display就实现绿色的头，红头鸭就实现红色的头。

如今让全部的鸭子都能飞，实现起来也比較简单，在父类里面加入一个fly的方法就能够了。相同的道理假设须要全部的鸭子都会叫，在父类里面加入quack方法就能实现。

那么问题来了，如今我们有一仅仅橡皮鸭也继承于父类。橡皮鸭会叫不会飞。可是它不会像真鸭子那样呱呱叫，橡皮鸭仅仅能吱吱叫。

我们仅仅能在橡皮鸭子类覆盖父类的fly方法让它什么也不做。然后覆盖quack方法让它吱吱叫。

再延伸一下如今又来了一仅仅木头假鸭不会飞也不会叫。相同让它继承父类然后覆盖父类的fly和quack方法。让这两个方法什么也不做。

这样做确实把橡皮鸭和木头鸭都实现了，可是橡皮鸭中根本不须要fly方法，木头鸭中也不须要fly和quack方法。却都要在写一遍覆盖掉父类。简直就是画蛇添足。

更痛苦的是再加入新的鸭子进来就得考虑是不是须要覆盖父类的fly和quack。那怎么办好呢？

这时候我们就须要把应用中可能变化的部分独立出来。不会再影响到其它部分。

在这个样例中也就是把飞行行为和叫行为从Duck类中分离出来。鸭子类就不再须要知道行为的实现细节。

类图例如以下：

代码实现：

//鸭子类
public abstract class Duck{
	FlyBehavior flyBehavior;//实例化飞行对象
	QuackBehavior quackBehavior;//实例化叫对象
	public Duck(){
		
	}
	public abstract void display();//表现的虚方法
	
	
	public void performFly(){
		flyBehavior.fly();
	}
	
	public void performQuack(){
		quackBehavior.quack();
	}
	
	public void swim(){
		System.out.println("All ducks float,even decoys");
	}
}

//绿头鸭类
public class MallardDuck extends Duck{
	public MallardDuck(){
		quackBehavior=new Quack();
		flyBehavior=new FlyWithWings();
	}
	
	public void display(){
		System.out.println("I'm a real Mallard duck");
	}
}

//飞行行为接口
public interface FlyBehavior{
	public void fly();
}

//会飞行为实现
public class FlyWithWings implements FlyBehavior{
	public void fly(){
		System.out.println("I'm flying!");
	}
}

//不会飞行为实现
public class FlyNoWay implements FlyBehavior{
	public void fly(){
		System.out.println("I can't fly");
	}
}

//叫行为接口
public interface QuackBehavior{
	public void quack();
}

//呱呱叫行为实现
public class Quack implements QuackBehavior{
	public void quack(){
		System.out.println("Quack");
	}
}

//不会叫行为实现
public class MuteQuack implements QuackBehavior{
	public void quack(){
		System.out.println("<Silence>");
	}
}

//吱吱叫行为实现
public class Squeak implements QuackBehavior{
	public void quack(){
		System.out.println("Squeak");
	}
}

//主函数
public class MiniDuckSimulator{
	public static void main(String[] args){
		Duck mallard=new MallardDuck();
		mallard.performQuack();
		mallard.performFly();
	}
}

执行结果：

长处：

1、策略模式提供了管理相关的算法族的办法。

策略类的等级结构定义了一个算法或行为族。

恰当使用继承能够把公共的代码转移到父类里面，从而避免反复的代码。

2、策略模式提供了能够替换继承关系的办法。继承能够处理多种算法或行为。假设不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每个子类提供一个不同的算法或行为。
可是。这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或採取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。

3、使用策略模式能够避免使用多重条件转移语句。

多重转移语句不易维护，它把採取哪一种算法或採取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。

缺点：

1、client必须知道全部的策略类，并自行决定使用哪一个策略类。这就意味着client必须理解这些算法的差别，以便适时选择恰当的算法类。换言之，策略模式仅仅适用于client知道全部的算法或行为的情况。

2、策略模式引起了很多战略。每个类将有详细的策略，以一个新的类。
有时可以保存取决于环境通过国家client内。该策略将被设计为共享，这样的策略类实例可以是不同的client使用。
换一种说法。轻量级的模式可以用于减少对象的数量。