策略模式

转自：http: //www.cnblogs.com/colinsong/archive/2009/03/02/1401723.html —————————————————————————————————————————————— 一、概念 策略模式（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对象

一、概念 策略模式（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. 二、我的理解 其实这个策略模式和简单工厂模式一样

一、概念 策略模式（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. 二、我的理解 其实这个策略模式和简单工厂模式一样

本文通过运用设计模式比没用设计模式的优势在哪？ 设计模式主要是要抓住稳定部分和易变部分，文章结尾会指出。 非策略模式 #include <iostream> using namespace std; //以上班乘坐的交通工具为例 //需要步行和乘公交车去上班 enum TYPE { WALK, TRANSIT }; class GoWork { public: void go(TYPE type) { if (type == WALK) { cout << "走路去上班" << endl; } else if (type == TRANSIT ){ cout << "坐公交去上班" << endl; } } }; //现在又增加了地铁的出行方式 enum TYPE2 { WALK2, TRANSIT2, SUBWAY2 //改动部分 }; class GoWork2 { public: void go(TYPE2 type) { if (type == WALK2) { cout << "走路去上班" << endl; } else if (type == TRANSIT2) { cout << "坐公交去上班" << endl; } else if (type == SUBWAY2) { //改动部分 cout << "坐地铁去上班" << endl; } } }; int

设计模式之策略模式在设计一群鸭子中的应用 记得以前刚接触JAVA程序的时候，申请一个QQ群，结果被拒绝，回复是：你懂设计模式和框架不？真是让人汗颜！ 近日看了一篇有关策略模式的文章，感觉写的不错，原文是PDF，不便于大家在网页上阅读，于是自己按照其大意进行了组织和整理了一下，发出来大家共赏 使用模式最好的方式是：「把模式装进脑子中，然后在你的设计和已有的应用中，寻找何处 可以使用这些模式。」以往是代码复用，那么现在则是经验复用。 让我们来看看什么叫策略模式？ 『策略模式』把易于变化的行为分别封装起来，让它们之间可以互相替换， 让这些行为的变化独立于拥有这些行为的客户。 听起来有些过于概括了，在实际运用中怎么处理才能完成它所描述的让让这些行为的变化独立于拥有这些行为的客户呢？ 第一个设计原则： 找出应用中可能需要变化之处，把它们独立出来， 不要和那些不需要变化的代码混在一起。 也就是说: 如果每次新的需求一来， 都会变化到某方面的代码， 那么你就可以确定， 这部分的代码需要被抽出来， 和其他闻风不动的代码有所区隔。 把会变化的部分取出并封装起来，以便以后可以轻易地扩充此部分，而不影响不需要变化的其他部分。这样的概念很简单，几乎是每个设计模式背后的精神所在。 所有的模式都提供了一套方法让「系统中的某部分改变不会影响其他部分」。 这样的结果如何？代码变化之后，出其不意的部分变得很少

Head First定义： 策略模式定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 策略模式的设计原则主要有三个： 找出应用中可能需要变化的部分，把它们独立起来。 针对接口编程，而不是针对实现编程。 多用组合，少用继承。 举个例子 现在需要设计一个鸭子类（Duck），有很多不同的鸭子（红头鸭、绿皮鸭、橡皮鸭、木头鸭...），所以Duck为这些鸭子的父类。 要求如下：每种鸭子都有自己的外形特征；鸭子都有游泳的行为；有些鸭子可能会飞（玩具鸭就不会飞）；有些鸭子可能会叫（木头鸭就不会叫）；不同种类的鸭子可能叫的不一样。 （1）首先我们将鸭子共有的特征行为抽象成方法：swim（游泳）和display（外形） swim是不会变的，用具体的方法实现。而每中鸭子的外形不一样，所以display可以设计为抽象方法，由具体的子类来实现。 （2）将需要变化的部分独立出来（原则1）：fly（飞行）和quack（叫） fly抽象成接口FlyBehavior，该接口有两个具体的实现类，一个实现鸭子的飞行，另一个实现不会飞。（这里也就是策略模式定义所说的算法族） quack抽象成接口QuackBehavior，该接口有三个具体的实现类，分别实现真实鸭子的瓜瓜叫、橡皮鸭子的吱吱叫、木头鸭子的不会叫。（同理，这也是个算法族）

参考博文：https://www.cnblogs.com/lewis0077/p/5133812.html 侵权删除 2019-06-17 11:39:49 策略模式（Strategy） 什么是设计模式 ： 定义了 一系列的算法（多种实现子类） ，并将每一个算法 封装（通过父类策略引用访问具体子类的算法） 起来，使每个算法可以相互替代，使算法本身和使用算法的客户端分割开来，相互独立。（客户端和具体算法均依赖抽象的策略） 优点： 符合设计模式中的开闭原则（在不修改既有代码的基础上扩展功能）。 适用性： 一个需求有多种不同算法的场合。（不固定的 if-else 场合一般是策略模式的用武之地） 基本代码如下： 1 //接口或抽象类，策略接口 2 public interface Strategy{ 3 //定义抽象的算法方法 4 public void algorithMethod(); 5 } 1 //具体的策略1实现 2 public class ConcreteStrategy1 implements Strategy{ 3 public void algorithmMethod(){ 4 //........具体策略1的方法体 5 } 6 } //具体的策略2实现 public class ConcreteStrategy2 implements Strategy{ public

定义（百度百科）： 策略模式是指对一系列的算法定义，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。 具体代码： public class Client { public static void main(String[] args) { Strategy strategyA = new StrategyA(); Strategy strategyB = new StrategyB(); Context context = new Context(strategyA); context.operation(); context = new Context(strategyB); context.operation(); } } public class Context { private Strategy strategy; Context(Strategy strategy) { this.strategy = strategy; } void operation() { strategy.operation(); } } public interface Strategy { void operation(); } public class StrategyA implements Strategy { @Override

策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法， 减少了各种算法类与使用算法类之间的耦合 [DPE]。 策略模式就是用来 封装算法 的，可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性[DPE]。 策略模式的Strategy 类层次为Context定义了一系列的可供重用的算法或行为，继承有助于析取 出这些算法中的公共功能[DP]。 此模式让算法的变化，不会影响到使用算法的客户。 客户端需声明一个Context类，创建Strategy实例来初始化Strategy变量，由ContextInterface调用Strategy的AlgorithmInterface()。 与简单工厂模式结合时 ，只需识别Context类，并传入一定的参数，在Context内部根据参数来实例化不同的Strategy类，而后调用其算法实现AlgorithmInterface()，这种做法使得 耦合更加降低 。 来源： CSDN 作者： Arururururu 链接： https://blog.csdn.net/unirrrrr/article/details/104147586

主要解决： 在有多种算法相似的情况下，使用 if...else 或 switch...case 所带来的复杂性和臃肿性 优点 算法多样性，且具备自由切换功能； 有效避免多重条件判断，增强了封装性，简化了操作，降低出错概率； 扩展性良好，策略类遵顼 里氏替换原则 ，可以很方便地进行策略扩展； 缺点 策略类数量增多，且所有策略类都必须对外暴露，以便客户端能进行选择； 核心 对一个操作，需要执行多个需要判断的类似步骤，可以提供统一的封装，外部直接可选择性使用这些封装，不关心内部逻辑 去掉判断语句，直接配置式使用 实际案例 实现更优雅的表单验证 游戏里的角色计分器 棋牌类游戏的输赢算法 const obj = { A: (num) => num * 4, B: (num) => num * 6, C: (num) => num * 8 } const getSum =function(type, num) { return obj[type](num) } 　　 来源： https://www.cnblogs.com/bigman-bugman/p/12247831.html