策略模式

3.3 Context和Strategy的关系 在策略模式中，通常是上下文使用具体的策略实现对象，反过来，策略实现对象也可以从上下文获取所需要的数据，因此可以将上下文当参数传递给策略实现对象，这种情况下上下文和策略实现对象是紧密耦合的。 在这种情况下，上下文封装着具体策略对象进行算法运算所需要的数据，具体策略对象通过回调上下文的方法来获取这些数据。 甚至在某些情况下，策略实现对象还可以回调上下文的方法来实现一定的功能，这种使用场景下，上下文变相充当了多个策略算法实现的公共接口，在上下文定义的方法可以当做是所有或者是部分策略算法使用的公共功能。 但是请注意，由于所有的策略实现对象都实现同一个策略接口，传入同一个上下文，可能会造成传入的上下文数据的浪费，因为有的算法会使用这些数据，而有的算法不会使用，但是上下文和策略对象之间交互的开销是存在的了。 还是通过例子来说明。 1：工资支付的实现思路 考虑这样一个功能：工资支付方式的问题，很多企业的工资支付方式是很灵活的，可支付方式是比较多的，比如：人民币现金支付、美元现金支付、银行转账到工资帐户、银行转账到工资卡；一些创业型的企业为了留住骨干员工，还可能有：工资转股权等等方式。总之一句话，工资支付方式很多。 随着公司的发展，会不断有新的工资支付方式出现，这就要求能方便的扩展；另外工资支付方式不是固定的，是由公司和员工协商确定的

查看本人文章索引请通过 http://www.cnblogs.com/seesea125/archive/2012/04/17/2453256.html 一、定义 策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。 二、概述 应用场景： 　　1、 多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。 　　2、 需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。 　　3、 对客户隐藏具体策略(算法)的实现细节，彼此完全独立。 三、代码实现 需求：商场收费系统，根据商品的单价和数量，得出的总结可以"正常收费", "打八折","满300返100", "打七折", "打五折"等等。 代码如下： abstract class CashSuper { public abstract double acceptCash(double money); } //正常收费子类 class CashNormal : CashSuper { public override double acceptCash(double money) { return money; } } //打折收费子类 class CashRebate : CashSuper { private

注意：委派模式不在23种设计模式中，但是在spring 中大量使用到，非常猖狂地用到这个模式。所以我们不得不去撩一下这个模式。 委派模式=静态代理+策略模式 他们组合起来的一种特殊设计模式 例如： 1、boss--->项目经理------》员工A、员工B、员工C 2、dispatcherSelvert就是用到这个委派模式。将URL进行解析和分发到对应的controller上。 代理模式注重：处理过程 策略模式注重：扩展性，用户只能选择，不能修改内容 委派模式注重：内部的灵活度 来源： https://www.cnblogs.com/vingLiu/p/10842159.html

1 概念 策略模式也叫政策模式，是一种比较简单的模式，其定义是 定义一组算法，将每个算法都封装起来，并且使它们之间可以互换 2 概念理解 策略模式使用的是面向对象的继承和多态机制，将算法实现从业务逻辑中剥离出来成为一系列独立的算法类，每个算法实现相同的接口就可以实现相互转换。 策略模式通用类图： Context封装角色 上下文角色，一般持有策略的引用，进行对策略的调用，具体的策略对象也可以从上下文角色中获取所需要的数据，可以将上下文当做参数传入到具体的参数中，具体策略通过回调上下文来获取所需要的数据。 Strategy抽象策略角色 策略、算法家族的抽象，通常为接口，定义每个策略或者算法必须具有的方法和属性。 ConcreteStrategy具体策略角色 实现抽象策略中的操作，该类含有具体的算法。 3 应用场景 多个类存在算法和行为上类似的场景 算法自由切换的场景 屏蔽算法规则的场景 4 优缺点 4.1 策略模式优点 算法可以自由切换 拓展性良好 避免使用多重条件判断 使用了策略模式后，可以由其他模块决定采用何种策略，策略对外提供的访问接口就是封装类。 4.2 策略模式的缺点 策略类数量增多 每个策略都是一个类，复用可能性小，类数量增多 所有策略对外暴露 上层模块需要知道哪些策略选择取调用哪个策略，这违背了迪米特法则，不过这个可以通过工厂模式方法和代理模式或者享元模式来修正这个缺陷。

一、策略模式的定义 策略模式是一种比较简单的模式，也叫做政策模式，其定义如下:定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。 策略模式使用的是面向对象的继承和多态机制，我们看看策略模式的三个角色: 1.Context封装角色 它也叫上下文角色，起承上启下封装作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。 2.Strategy抽象策略角色 策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。 3.ConcreteStrategy具体策略角色 实现抽象策略中的操作，该类含有具体的算法。 二、策略模式的应用 1.策略模式的优点 a.算法可以自由切换 这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供”可自由切换”的策略。 b.避免使用多重条件判断 如果没有策略模式，我们想想看会是什么样子？ 一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。 c.扩展性良好 只要实现接口就可以，其他都不用修改，类似于一个可反复拆卸的插件，大大符合OCP原则(开闭原则)。 2

释义 策略模式和多态很相似 可以理解为定义了一个统一的接口，有许多不同的实现类，可以自由选择不同的实时类去执行。 实现 上代码： 定义一个统一的接口： [JavaScript] 纯文本查看 复制代码 ? 1 2 3 4 5 public interface CalcStrategy { void calc(String ql); } 定义几个实现类 [JavaScript] 纯文本查看 复制代码 ? 1 2 3 4 5 6 7 8 @Service public class HelloService implements CalcStrategy { @Override public void calc(String ql) throws SupportPortalException { System.out.println( "hello : " + ql); } } [JavaScript] 纯文本查看 复制代码 ? 1 2 3 4 5 6 7 8 @Service public class WorldService implements CalcStrategy { @Override public void calc(String ql) throws SupportPortalException { System.out.println( "world : " + ql)

一，总体概要 1，笔者浅谈 策略模式，又叫算法簇模式，就是定义了不同的算法，并且之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 策略模式和 工厂模式 有一定的类似,策略模式相对简单容易理解,并且可以在运行时刻自由切换。工厂模式重点是用来创建对象。 策略模式应用比较广泛，比如：我们现在要定义数据交换格式，现有三种方案可选1，XML 2，JSON 3，CSV就 可以使用策略模式实现。 这里我要强调的是------ 我们是针对不同数据源选择不同方案，针对的都是同一事物做相同意图的操作只是方案不同。 代码实现如下： 1 var dataSourceVendor = { 2 xml : { 3 get : function(){ 4 console.log("XML数据源") ; 5 } 6 } , 7 json : { 8 get : function(){ 9 console.log("JSON数据源") ; 10 } 11 } , 12 csv : { 13 get : function(){ 14 console.log("CSV数据源") ; 15 } 16 } 17 } ; 18 console.log("选择的数据源：" + dataSourceVendor["json"]["get"]()) ; 注意到了吧，它们的接口是一致的，也就是意图操作一致的，只是实现不同。

2006.9.25 李建忠 算法与对象的耦合 对象可能经常需要使用多种不同的算法，但是如果变化频繁，会将类型变得脆弱…… 动机（Motivation） 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？ 意图（Intent） 定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法可独立于使用它的客户而变化。 ——《设计模式》GoF 例说Strategy模式应用 这个程序有两个可能的变化点：当枚举类型增加时，即处理的方法增加，那么Process函数需要修改补充一个if else分支；当我们想对分支1的处理ProcessA进行更改时，也要对Process函数进行修改。 针对上面的问题，我们首先想到的是把ProcessA写成受保护的虚函数（在OO中我们一般把虚函数都写成受保护的函数，因为它是能改变类的行为的函数，一般情况下只应该作为子类和父类之间的协议出现）。 Strategy模式的设计 把Cart类和ProcessStrategy类作为对象组合的方式使用。IProcessStrategy表达的是一个算法抽象。 抽象和具体算法 客户程序 这样算法就可以动态地去改变了

它定义了一系列的算法，并将每个算法封装起来，而且使他们还可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。 优点： 　　1）简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。 　　2）避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。 　　3）遵守大部分GRASP原则和常用设计原则，高内聚、低耦合。 缺点： 　　1）因为每个具体策略类都会产生一个新类，所以会增加系统需要维护类的数量。 　　2）在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。 进一步优化可以将策略模式与简单工厂模式相结合，选择所用具体实现的职责也可以由Context对象承担，这就最大化的减轻了客户端的职责。 结合策略模式与简单工厂模式实现的简单收银系统代码： Strategy.h: 1 #include<iostream> 2 #include<string> 3 #include<memory> 4 using namespace std; 5 6 //strategy抽象类，用作接口 7 class Strategy 8 { 9 public: 10 virtual double GetResult(double money) = 0; 11 virtual ~Strategy() 12 { 13 cout<<" in the

一、概念 策略模式（Strategy）： 它定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。（原文：The Strategy Pattern defines a family of algorithms,encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.） 图1 策略模式类图 　优点： 　　1、 简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。 　　2、 避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。 3、 遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。 　　缺点： 　　1、 因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。 2、 在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。（这本身没有解除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由Context来承担，这就最大化的减轻了客户端的压力。） 参考阅读： 1. 2. 二、我的理解 其实这个策略模式和简单工厂模式一样