设计模式之策略模式

1. 定义

策略模式：分别封装行为接口，实现算法族，超类里放行为接口对象，在子类里具体设定行为对象。原则就是：分离变化部分，封装接口，基于接口编程各种功能。此模式让行为算法的变化独立于算法的使用者。

策略模式定义了算法簇，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法上客户。

策略模式的结构图如下：

策略模式

Strategy: 定义所有支持的算法的公共接口抽象类.
ConcreteStrategy: 封装了具体的算法或行为，继承于Strategy
Context: 用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用。

Strategy模式有下面的一些优点：

1) 相关算法系列 Strategy类层次为Context定义了一系列的可供重用的算法或行为。 继承有助于析取出这些算法中的公共功能。
2) 提供了可以替换继承关系的办法： 继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个Context类的子类，从而给它以不同的行为。但这会将行为硬行编制到 Context中，而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后你得到一堆相关的类 , 它们之间的唯一差别是它们所使用的算法或行为。 将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展。
3) 消除了一些if else条件语句 ：Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。当不同的行为堆砌在一个类中时 ,很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。含有许多条件语句的代码通常意味着需要使用Strategy模式。
4) 实现的选择 Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间 /空间权衡取舍要求从不同策略中进行选择。

Strategy模式缺点:

1
2
3

1)客户端必须知道所有的策略类，并自行决定使用哪一个策略类:  本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时 , 才需要使用Strategy模式。
2 ) Strategy和Context之间的通信开销 ：无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。因此很可能某些 ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的 ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题 , 那么将需要在Strategy和Context之间更进行紧密的耦合。
3 )策略模式将造成产生很多策略类：可以通过使用享元模式在一定程度上减少对象的数量。 增加了对象的数目 Strategy增加了一个应用中的对象的数目。有时你可以将 Strategy实现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由 Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的 Strategy不应在各次调用之间维护状态。

2. 具体代码

从项目“模拟鸭子游戏开始”：

首先定义一个超类DUCK：

public abstract class Duck {

	public Duck() {
	}

	public void Quack() {
		System.out.println("~~gaga~~");
	}

	public abstract void display();

	public void swim() {
		System.out.println("~~im swim~~");
	}

然后有GreenHeadDuck继承Duck ，并且重写父类的方法：

public class GreenHeadDuck extends Duck {

	@Override
	public void display() {
		System.out.println("**GreenHead**");
	}

同理可有RedHeadDuck等继承了DUCk

现在我们有一个新的需求;

(1)添加会飞的鸭子

我们想的就是在DUCK这个类里面添加一个方法

public abstract class Duck {
    ...	
	public void Fly() {
			System.out.println("~~im fly~~");
		}

然后这样的话就导致了所有的鸭子都是会飞的，那要是有些鸭子不会飞呢，

然后我们想的是在子类里面重写这个方法，例如

public class GreenHeadDuck extends Duck {
    ...
    @Override
	public void Fly() {
		System.out.println("~~no fly~~");
	}

这样的话所有的不会飞的鸭子全部要改动，这样的话工作量很大，上面的设计思想就是我们经常会想到的方法，也就是用面向对象的方式去设计。

继承的问题：对类的局部改动，尤其超类的局部改动，会影响其他部分。影响会有溢出效应

而且超类挖的一个坑，每个子类都要来填，增加工作量，复杂度O(N^2)。不是好的设计方式

需要新的设计方式，应对项目的扩展性，降低复杂度：
1）分析项目变化与不变部分，提取变化部分，抽象成接口+实现；
2）鸭子哪些功能是会根据新需求变化的？叫声、飞行…

所以设计两个接口一个是飞行，一个是叫声

1
2
3

public interface FlyBehavior {
	void fly();
}

1
2
3

public	interface QuackBehavior {
	void quack();
}

然后不同的叫声各种实现这个叫声接口例如

public	class GaGaQuackBehavior implements QuackBehavior
{
	@Override
	public void quack() {
		// TODO Auto-generated method stub
		System.out.println("__GaGa__");
	}	
}

public	class GeGeQuackBehavior implements QuackBehavior
{
	@Override
	public void quack() {
		// TODO Auto-generated method stub
		System.out.println("__GeGe__");
	}
}

重新设计DUCK这个类

public abstract class Duck {

	FlyBehavior mFlyBehavior;
	QuackBehavior mQuackBehavior;

	public Duck() {

	}

	public void Fly() {
		mFlyBehavior.fly();
	}

	public void Quack() {
		mQuackBehavior.quack();
	}

	public abstract void display();

	public void SetQuackBehavoir(QuackBehavior qb) {
		mQuackBehavior = qb;
	}

	public void SetFlyBehavoir(FlyBehavior fb) {
		mFlyBehavior = fb;
	}

	public void swim() {
		System.out.println("~~im swim~~");
	}
}

重写DUCK的子类GreenHeadDuck ：

public class GreenHeadDuck extends Duck {
	public GreenHeadDuck() {
		mFlyBehavior = new GoodFlyBehavior();      //实例化的时候必须要传入的参数，因为在具体的父类中会用到，并且在用的时候用的是父类中的方法，而且你不必去计较底层是怎么实现的
		mQuackBehavior = new GaGaQuackBehavior();
	}
	@Override
	public void display() {...}
}

这样的话在添加不同的新的需求的时候可以直接添加新的接口和具体的实现类，最后在你需要的地方通过这些实现类来实例化你的对象就可以了

public static void main(String[] args) {

		Duck mGreenHeadDuck = new GreenHeadDuck();
		Duck mRedHeadDuck = new RedHeadDuck();
    
		mGreenHeadDuck.display();
		mGreenHeadDuck.Fly();
		mGreenHeadDuck.Quack();
		mGreenHeadDuck.swim();
		mRedHeadDuck.display();
		mRedHeadDuck.Fly();
		mRedHeadDuck.Quack();
		mRedHeadDuck.swim();
		mRedHeadDuck.display();
		mRedHeadDuck.SetFlyBehavoir(new NoFlyBehavior());
		mRedHeadDuck.Fly();
		mRedHeadDuck.SetQuackBehavoir(new NoQuackBehavior());
		mRedHeadDuck.Quack();
	}

最终通过策略模式设计实现的框架如下图所示。