策略模式——你要用支付宝还是微信？

       在生活中我们有很多选择，你想喝一种饮料，你可以选择可乐，芬达，加多宝等等；你想去旅行，可以选择单车，步行，货车，火车。选择，很多。是的，用代码怎么去表达？一般情况下，很多人会选择if...else...这种表达方式，但是如果你拥有了更多的选择，想要添加进去或者修改，是在代码上直接再加一个还是修改？事实上，很对软件开发的工程中，代码的量相当庞大，牵一发而动全身是极其危险的。这时候，如何减少整个代码的关联性，增强代码的灵活性和可移植性。就变得很重要了，设计模式这种方式在一定程度上满足我们的要求，

       策略模式的策略体现在哪？就是你可以做出不同的决定，比如说你想喝可乐变成想喝加多宝了。这就做动态的改变对象的行为。因此策略模式多用于一下几个场景

           (1) 多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。

           (2) 类似if...else语句的多种条件转移的时候

       策略模式在不同的情况下做出不同的判断。隐藏实现的细节，消除耦合。下面我借一下别人图来看看整个UML中，策略模式是怎么运作的

实现一个策略接口，让context来拥有成员变量。需要用到哪种策略，我们用构造器来指定。(引用：http://www.cnblogs.com/jenkinschan/p/5645300.html)

理论还是要付诸于实践，我们看代码:

       举个例子。我写一个客户在超市结账时选择不同的支付方式，先写一个接口

public interface SuperMarketWay {public void getPay();}

下面用支付宝和微信来实现接口

public class WeixinPay implements SuperMarketWay{@Overridepublic void getPay() {// TODO Auto-generated method stubSystem.out.println("我选择用微信支付");}}

public class ZhifubaoPay implements SuperMarketWay{@Overridepublic void getPay() {// TODO Auto-generated method stubSystem.out.println("我选择使用支付宝支付");}}

创建一个客户端的用户，包含超市的策略和支付的方式

public class Custom {//超市的策略接口public SuperMarketWay smw;//包含购买方式public void customGetWay(){smw.getPay();}}

创建一个青年的类继承客户端，初始化支付宝的支付方式

public class Tennager extends Custom{public Tennager(){smw=new WeixinPay();}}

我们来进行测试

public class MainTest {public static void main(String[] args) {//测试青年的支付方式Custom young=new Tennager();young.customGetWay();}}

测试结果如下