在生活中我们有很多选择,你想喝一种饮料,你可以选择可乐,芬达,加多宝等等;你想去旅行,可以选择单车,步行,货车,火车。选择,很多。是的,用代码怎么去表达?一般情况下,很多人会选择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{
@Override
public void getPay() {
// TODO Auto-generated method stub
System.out.println("我选择用微信支付");
}
}
public class ZhifubaoPay implements SuperMarketWay{
@Override
public void getPay() {
// TODO Auto-generated method stub
System.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();
}
}
测试结果如下