设计模式（2）-----策略模式

一.策略模式的简单实现

        策略模式是替代使用大量的if else 或者 switch case 语句（不好维护，不够灵活）进行分类处理的一种方式方法。

        使用策略模式的核心逻辑如下：事物A     实现行为B      要通过具体动作C    来实现一个目的。举例，人（A）实现旅行行为(B)，通过具体动作C（飞机，火车，自行车）。

        所以，策略模式有三个组成部分。1.持有者上下文    2.行为的抽象层    3.行为的具体实现动作层。

举一个策略模式的简单例子：人使用不同的交通方式去旅行

        行为抽象层：

//同一行为的抽象类
interface TravelWay{
	public void go();//被具体动作重写的方法
}

        具体动作层：

//旅行行为的实现动作-----飞机
class Airplane implements TravelWay{
	public void go() {
		System.out.println("坐飞机去旅行");
	}
}

//旅行行为的实现动作-----自行车
class Bicycle implements TravelWay{
	public void go() {
		System.out.println("骑自行车去旅行");
	}
}

//旅行行为的实现动作-----火车
class Train implements TravelWay{
	public void go() {
		System.out.println("坐火车去旅行");
	}
}

        需要选择策略的上下文：

//持有策略的上下文类
class Person{
	
	private TravelWay travelWay;//此person的旅行策略
	
	public void goToTravel() {//人要去旅行的行为方法
		if(travelWay == null) {
			travelWay = new Bicycle();//默认的旅行方式
		}
		
		travelWay.go();
		
	}
	public void setTravelWay(TravelWay travelWay) {//设置本次旅行的方式
		this.travelWay = travelWay;
	}
}

        测试：

public static void main(String[] args) {
		Person p1 = new Person();
		p1.goToTravel();
		p1.setTravelWay(new Airplane());
		p1.goToTravel();
	}

        

二.策略模式的适用情况

        1.许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。
        2 .需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间 /时间权衡的算法。当这些变体实现为一个算法的类层次时 ,可以使用策略模式。
        3. 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。

        4.一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

三.策略模式的优缺点

        

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

缺点:

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

最后，本文是我从两篇文章中总结而来,在此抛砖引玉：

        对于策略模式的整体性把握-----点击打开链接

        策略模式的具体实现方法以及进一步使用策略模式实现需求功能-----点击打开链接