『设计模式』设计模式--策略模式
今天去超市买东西，买了50多块钱的东西，然后收钱的时候他多收了，明明会员要打白金会员打9折，黄金会员95折，我是白金会员因该是9折。 我问她：“你是不是不知道什么是策略模式” 她一脸茫然地看着我，“啊？先生请您再说一遍。” 我说：“我是白金会员，请选择白金会员的策略” 她说：“不好意思，您一年没来我们这里买过东西了，已经给您降档了！” 我说：“还有这操作？。。。。” 朋友觉得我为了几块钱这么墨迹，付完钱拉着我就走了，问我：“你说的什么模式怎么回事？” 我说超市收银系统就是很好的策略系统，就是一个典型策略模式。 多收了2块5，心疼死我了，我慢慢给你讲！
策略模式
策略模式的用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。
使用策略模式可以把行为和环境分割开来。环境类负责维持和查询行为类，各种算法则在具体策略类( ConcreteStrategy) 中提供。
由于算法和环境独立开来，算法的增减、修改都不会影响环境和客户端。当出现新的促销折扣或现有的折扣政策出现变化时，只需要实现新的策略类，并在客户端登记即可。策略模式相当于"可插入式(Pluggable)的算法"。
在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。
意图
策略模式是对算法的包装，是把使用算法的责任和算法本身分割开，委派给不同的对象管理。准备一组算法，并将每一个算法封装起来，使得它们可以互换。
优点：
策略模式可以避免让客户端涉及到不必要接触到的复杂的和只与算法有关的数据。 避免使用难以维护的多重条件选择语句。 更好的扩展。
缺点：
上述策略模式，把分支判断又放回到客户端，要改变需求算法时，还是要去更改客户端的程序。 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。 增加了对象的数目。 只适合扁平的算法结构。 本质：分离算法，选择实现。
策略模式和简单工厂模式的结合：把分支判断放到环境角色中。
解决简单工厂模式中提到的问题： ●关键:分支的switch依然去不掉 ●解决方法:依赖注入、反射、XML
涉及角色
环境(Context) 角色:持有一个Strategy类的引用(上下文对象)，负责和具体的策略类交互。 抽象策略(Strategy)角色:这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接只。 具体策略(ConcreteStrategy) 角色:包装了相关的算法或行为。
使用场景：
- 出现同关个算法，有很多不同的实现的情况,一个系统需要动态地在几种算法中选择一种，可以使用策略模式来把这些“不同的实现”实现成为一个算法的类层次
- 出现抽象一个定义了很多行为的类，并且是通过多个if-else语句来选择这些行为的情况，可以使用策略模式来代替这些条件语句
- 如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
模式讲解
策略模式功能：把具体算法从具体业务处理中独立 策略模式与if-else语句：多个if-else出现考虑使用策略模式 算法的平等性：策略算法是形同行为的不同实现 谁来选择具体策略算法：客户端；由上下文来选择具体的策略算法
UML图
实现
//抽象算法类
public abstract class Strategy
{
//算法方法
public abstract void AlgorithmInterface();
}//具体算法A
public class ConcreteStrategyA extends Strategy
{
//算法A实现方法
@ override
public void AlgorithmInterface()
{
System.out.println("算法A实现");
}
} //具体算法B
public class ConcreteStrategyB extends Strategy
{
//算法B实现方法
@ override
public void AlgorithmInterface()
{
System.out.println("算法B实现");
}
}//具体算法C
public class ConcreteStrategyC extends Strategy
{
//算法C实现方法
@ override
public void AlgorithmInterface()
{
System.out.println("算法C实现");
}
} //上下文
public class Context
{
Strategy strategy;
public Context(Strategy strategy)
{
this.strategy = strategy;
}
//上下文接口
public void ContextInterface()
{
strategy.AlgorithmInterface();
}
}
} public class Client {
public static void main(String[] args) {
Context context;
context = new Context(new ConcreteStrategyA());
context.ContextInterface();
context = new Context(new ConcreteStrategyB());
context.ContextInterface();
context = new Context(new ConcreteStrategyC());
context.ContextInterface();
Console.Read();
}
}
深入：
在策略模式中，通常是上下文使用具体的策略实现对象，反过来，策略实现对象也可以从上下文获取所需要的数据，因此可以将上下文当参数传递给策略实现对象 在这种情况下，上 下文封装着具体策略对象进行算法运算所需要的数据，具体策略对象通过回调上下文的方法来获取这些数据。
两种方式实现策略模式
1.扩展上下文的方式 优点： ●所有策略的实现风格更统一，策略需要的数据都统一从上下文来获取，这样在使用方法上也很统一; ●在上下文中添加新的数据，别的相应算法也可以用得上，可以视为公共的数据。
缺点: ●如果只有一个特定的算法来使用这些数据，那么这些数据有些浪费; ●另外每次添加新的算法都去扩展上下文，容易形成复杂的上下文对象层次。
2.在策略算法的实现上添加自己需要的数据的方式 优点: ●比较好想，实现简单
缺点: ●跟其它策略实现的风格不一致。 ●外部使用这些策略算法的时候也样了，不太好以一个统一的方式来动态切换策略算法。
写在最后： 我叫风骨散人，名字的意思是我多想可以不低头的自由生活，可现实却不是这样。家境贫寒，总得向这个世界低头，所以我一直在奋斗，想改变我的命运给亲人好的生活，希望同样被生活绑架的你可以通过自己的努力改变现状，深知成年人的世界里没有容易二字。目前是一名在校大学生，预计考研，热爱编程，热爱技术，喜欢分享，知识无界，希望我的分享可以帮到你！ 如果有什么想看的，可以私信我，如果在能力范围内，我会发布相应的博文！ 感谢大家的阅读！?你的点赞、收藏、关注是对我最大的鼓励！
腾讯云开发者
