设计模式之策略模式（Strategy）

  举例说明策略模式，商场进行促销活动时，有如下优惠活动 一、满100减20 二、一件5折，二件三折 三、有些商品是固定8折 四、有些商品不参与促销活动 针对上述需求，在用代码进行封装时，如果按部就班的写就会将代码写到一个类中，之后根据不同情况进行判断之后进行相应的处理，但是这样做的坏处就是当有新的促销活动要加进来时，如：新追加一种促销活动当消费满500的情况下，送手提包一个，这时就需要修改整个程序，追加新的判断，因为是修改程序就可能将之前对的逻辑修正错了，也会需要对所有代码进行重新编译，这样做带来的代价十分昂贵，而且违背了设计的一个原则--开放封闭原则 即对修改关闭，对扩展开放，所以为了满足上述需求就要将代码进行合理的oo设计，将整个应用进行分层，简单分，分成客户端和服务处理端，为了达到的目的是服务处理端将来发生变化时不要影响客户端代码，即追加一种活动，不需要修改客户端代码，或是不需要大量修改客户端代码

设计思想：分析这个需求中变化的部分是商品的促销活动部分，如果将这部分变化的部分单独提出来进行抽象化处理，比如说有抽象类A表示促销活动行为（即变化的行为抽象成为类）如下：
package com.Strategy;

public abstract class A {

abstract void sale();

}
A表示将变化部分封装起来的抽象类，抽象方法sale（）为变化部分，即不同的促销活动会有不同的处理如：
A1活动
package com.Strategy;

public class A1 extends A {

@Override
void sale() {
System.out.println("A1");

}

}

A2活动
package com.Strategy;

public class A2 extends A {

@Override
void sale() {
System.out.println("A2");

}

}
分别表示两种促销活动
这样在销售这个类
package com.Strategy;

public class SaleClass {
A a;
public SaleClass(A arg1) {
this.a = arg1;
}

public void sale() {
a.sale();
}

}

就会根据实际的促销活动实例进行促销，即new 销售这个类时 构造方法中指定了什么促销活动，当程序执行的时候就会执行相应的促销活动，这里的A1、A2就是2个策略
在实际的生活中可能这个销售的类也需要抽象化,因为可能不只一种销售,可能同时存在多种销售并存的情况,至于客户端即客户,想选择哪种促销活动客户会自己选择
重新整理的代码如下:
package com.Strategy2;

public interface A {

void sale();

}

策略A1:
package com.Strategy2;

public class A1 implements A {

public void sale() {
System.out.println("A1");

}

}


策略A2:
package com.Strategy2;

public class A2 implements A {

public void sale() {
System.out.println("A2");

}

}

抽象销售
package com.Strategy2;

abstract public class AbstractSale {
A a;
abstract void sale();
public void test1() {
System.out.println("test1");
}
public void test2() {
System.out.println("test2");
}
public void test3() {
System.out.println("test3");
}
}

销售活动1

package com.Strategy2;


public class SaleClass1 extends AbstractSale {

public SaleClass1() {
a = new A1();
}

@Override
void sale() {
a.sale();

}

}

促销活动2
package com.Strategy2;


public class SaleClass2 extends AbstractSale {

public SaleClass2() {
a = new A2();
}

@Override
void sale() {
a.sale();

}

}

客户选择A1这种促销活动
package com.Strategy2;

public class Client {

/**
* @param args
*/
public static void main(String[] args) {
AbstractSale a = new SaleClass1();
a.sale();
}

}

如果客户选择A2折冲促销活动客户端代码如下:
package com.Strategy2;


public class SaleClass2 extends AbstractSale {

public SaleClass2() {
a = new A2();
}

@Override
void sale() {
a.sale();

}

}
这样就将实际当中变化的部分,活动单独进行封装,当有新的活动增加时只需要追加相应的策略即可，上述策略赋值时应用的都是构造方法，当然也可以利用set方法进行赋值，其结果是一样的

这么说可能觉得看着太迷糊，说个实际当中的项目吧，一个简答的设计模式应用
应用为第三方系统提供查询服务
但是提供的服务有很多中，有查询服务，更新服务，新增服务等，但是传递的参数都是一样的，都是xml，这里所说的一样不是文字意义上的一样，是说数据结构，由于提供的每种服务都会有很多种情况，比如查询服务，第三方系统可能有写时候需要要属性1、属性2，有的时候可能要属性2、属性3，当然传递的xml内容也不一样，即查询条件不一样，例如当传递
<?xml version="1.0" encoding="UTF-8"?>
<root>
<name>wang</name>
<sex>1</sex>
</root>
的时候要查询属性1、属性2
当传递
<?xml version="1.0" encoding="UTF-8"?>
<root>
<name>wang</name>
<age>1</age>
</root>
时需要返回属性2、属性3
那这时候就能应用到策略模式了，将查询操作进行抽象化，之后每种查询操作为一个策略，这样在提供服务的最前端根据不同的情况调用不同的策略

具体实现如下：
行为抽象接口：
import java.util.ArrayList;

public interface SearchInterface {
ArrayList<String> search();
}
实际的行为实现1：
import java.util.ArrayList;

public class Search1 implements SearchInterface {

public ArrayList<String> search() {
System.out.println("search1");
ArrayList<String> list = new ArrayList<String>();
list.add("search1");
return list;
}

}

实际的行为实现2：
import java.util.ArrayList;

public class Search2 implements SearchInterface {

public ArrayList<String> search() {
System.out.println("search2");
ArrayList<String> list = new ArrayList<String>();
list.add("search2");
return list;
}

}

对外提供服务的类
import java.util.ArrayList;

public class Search {
SearchInterface s;


public ArrayList<String> search() {
return s.search();
}

}
说明：此处对外提供服务的类为实体类还是抽象类还是接口因实际业务需求情况而定
此处的提供服务的类里面关于抽象行为的设置也可以应用spring的IOC进行设置，也可以在提供服务的类里面定义提供查询行为接口的集合，这样可以将所有策略一次性设定到集合中，这样根据第三方系统的特定值而决定采用list中的那个具体的行为来执行查询操作

总结策略模式中用到的原则：1、针对接口编程而不针对具体实现编程 2、开放封闭原则--对修改关闭对扩展开放 3、多用组合少用继承（“有一个”的关系比“是一个”的关系更好）


由于本人第一次写博客，写的是乌烟瘴气，所以您对付看吧，以后会逐步改善，希望多多指正，提出宝贵意见