策略模式

策略（Strategy）模式的定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。策略模式有以下优点： 多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句。 策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。 策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。 策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。 模式结构 策略模式是准备一组算法，并将这组算法封装到一系列的策略类里面，作为一个抽象策略类的子类。策略模式的重心不是如何实现算法，而是如何组织这些算法，从而让程序结构更加灵活，具有更好的维护性和扩展性，现在我们来分析其基本结构和实现方法。 策略模式的主要角色如下： 抽象策略（Strategy）类：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，环境角色使用这个接口调用不同的算法，一般使用接口或抽象类实现。 具体策略（Concrete Strategy）类

策略模式简单来说就是将业务和实现业务的具体方法剥离开来 依然以仓库拣货来说，合并拣货分单拣货是一种模式，但具体根据所出库单中的品是什么类型，从哪种类型仓库出，还是要有具体的拣货策略来生成拣货列表 比如 服装仓按动线进行拣货，快消仓分整拣散拣，数码仓的品要扫码标记SN与单据关系出库 那么就要根据各种不同的仓库划分出不同的拣货列表创建方式，这样就把拣货这个业务本身，和具体拣货列表的生成进行剥离。不写死在具体业务中 首先建立策略模式的顶层接口 package strategy; import java.util.List; import bean.PickDoc; import bean.PickList; /** 拣货策略顶层接口 @author zhousjmas@hotmail.com */ public interface IPickStrategy { public List<PickList> pickStrategy(List<PickDoc> list) ; } 然后依次建立服装，数码，快消3种仓库的具体拣货列表策略 package strategy; import java.util.List; import bean.PickDoc; import bean.PickList; /** 服装仓拣货策略 @author zhousjmas@hotmail.com */

策略模式（Strategy Pattern），我们可以和实际生活联在一起。比如我们每天上班的出行选择，可以是坐公交，也可以是开车、骑自行车等。 其实这种出行方式的选择就是策略模式的一种体现。 我们有一个抽象出来的 出行 概念： 出行() 然后可以有不同的具体的选择： 锻炼身体可以选择： 骑自行车() 开车方便的话，可以选择： 开车() 绿色出行除了骑行，也可以选择： 坐公交车() 其实不同的出行选择就是封装起来的对出行的不同的实现（算法）。 如下图所示： 策略模式有以下几个特点： 1、定义多个算法 2、封装算法 3、这多个算法可互换 我们可以看一下具体的代码： /** * 定义抽象接口 */ public interface Traffic { ​ public void goToWork (); } 公交： public class Bus implements Traffic { @Override public void goToWork () { System . out . println ( "坐公交车" ); } } 开车： public class Car implements Traffic { ​ @Override public void goToWork () { System . out . println ( "开车" ); } } 小明去上班：

　　前言：【 模式总览 】——————————by xingoo 　　模式意图 　　定义一系列的算法，把他们封装起来，使得算法独立于适用对象。 　　比如，一个系统有很多的排序算法，但是使用哪个排序算法是客户对象的自有。因此把每一个排序当做一个策略对象，客户调用哪个对象，就使用对应的策略方法。 　　 应用场景 　　1 当许多的类，仅仅是行为或者策略不同时，可以把行为或策略单独提取出来，这样主体的类就可以进行统一了。 　　2 需要使用不同的算法。 　　3 一个类定义了多种行为。 　　模式结构 　　Context 环境角色的，策略的调用者 class Context{ private Strategy strategy; public Strategy getStrategy() { return strategy; } public void setStrategy(Strategy strategy) { this.strategy = strategy; } public void operation(){ strategy.action(); } } 　　Strategy 策略的抽象，规定了统一的调用接口 interface Strategy{ public void action(); } 　　ConcreteStrategy 具体的策略 class

设计模式代表了最佳的实践，是开发人员在软件开发过程中面临一般问题的解决方案。熟悉了设计模式，是对自己代码设计的一个升华，所以近段时间的学习就以这个结尾吧。 很早之前就读过一本设计模式的入门书籍——《HeadFirst 设计模式》，但是仅仅只是了解各个设计模式和书上的一些简单的例子，很少看到过现实中的代码实现。没有具体的实现，学习设计模式都是空白的。近段时间学习JUC、Spring、Mybatis、Dubbo源码也仅仅是跟踪源码，熟悉实现流程原理，并没有具体研究里面用到的设计模式。 设计模式再入门，也可以当做是之前学习源码的一个复习。 来源： https://www.cnblogs.com/wqff-biubiu/p/12611841.html

假设现在要设计一个麦各类书籍的电子商务汪涵的(Shoping Card)系统，一个最简单的情况就是把所有货品的单价乘上数量，但是实际情况肯定要比这复杂。比如本网站可能对所有的教材类图书实行每本两元的折扣；对连环画类图书提供每本10%的促销折扣，而非教材类的计算机图书有5%的折扣；对其余书没有折扣。由于有这样复杂的折扣算法，使得价格计算问题需要系统地解决。 那么怎么样才能解决这个问题呢？ 其实，解决方法不止一种，例如我们可以把所有逻辑放在客户端利用条件语句判断决定使用哪一种算法；也可以利用继承在子类里面实现不同打折算法；还可以利用策略模式将环境和各种算法分开，将具体实现与客户端解耦。 实现这个策略的UML图如下： 抽象策略类(DiscountStrategy) package com.strategy.booksale; /** * 抽象策略类，定义了抽象算法 * @author LLS * */ abstract public class DiscountStrategy { //抽象方法 abstract public double calculateDiscount(); } 10%的折扣促销类(PercentageStrategy) package com.strategy.booksale; /** * 折扣销售图书类 * @author LLS * */ public

3 月，跳不动了？>>> 一、前言 随着美团外卖业务的不断迭代与发展，外卖用户数量也在高速地增长。在这个过程中，外卖营销发挥了“中流砥柱”的作用，因为用户的快速增长离不开高效的营销策略。而由于市场环境和业务环境的多变，营销策略往往是复杂多变的，营销技术团队作为营销业务的支持部门，就需要快速高效地响应营销策略变更带来的需求变动。因此，设计并实现易于扩展和维护的营销系统，是美团外卖营销技术团队不懈追求的目标和必修的基本功。 本文通过自顶向下的方式，来介绍设计模式如何帮助我们构建一套易扩展、易维护的营销系统。本文会首先介绍设计模式与领域驱动设计（Domain-Driven Design，以下简称为DDD）之间的关系，然后再阐述外卖营销业务引入业务中用到的设计模式以及其具体实践案例。 二、设计模式与领域驱动设计 设计一个营销系统，我们通常的做法是采用自顶向下的方式来解构业务，为此我们引入了DDD。从战略层面上讲，DDD能够指导我们完成从问题空间到解决方案的剖析，将业务需求映射为领域上下文以及上下文间的映射关系。从战术层面上，DDD能够细化领域上下文，并形成有效的、细化的领域模型来指导工程实践。建立领域模型的一个关键意义在于，能够确保不断扩展和变化的需求在领域模型内不断地演进和发展，而不至于出现模型的腐化和领域逻辑的外溢。关于DDD的实践，大家可以参考此前美团技术团队推出的《

3 月，跳不动了？>>> 1.什么是策略模式？ 策略模式是对算法的包装，是把使用的算法的责任和算法分割开来，委派给不同的对象管理，最终可以实现解决多重if判断问题。 下面会连接数据库使用 效果如下 项目结构如下 开始上代码 1.创建数据库 SET NAMES utf8mb4; SET FOREIGN_KEY_CHECKS = 0; -- ---------------------------- -- Table structure for payment_channel -- ---------------------------- DROP TABLE IF EXISTS `payment_channel`; CREATE TABLE `payment_channel` ( `ID` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID', `CHANNEL_NAME` varchar(32) NOT NULL COMMENT '渠道名称', `CHANNEL_ID` varchar(32) NOT NULL COMMENT '渠道ID', `strategy_bean_id` varchar(255) DEFAULT NULL COMMENT '策略执行beanid', PRIMARY KEY (`ID`,`CHANNEL_ID`) )

第一篇博客 本文来自 自己老师 的博客 http://blog.csdn.net/lovelion/article/details/7818983 题目：某软件公司为某电影院开发了一套影院售票系统，在该系统中需要为不同类型的用户提供不同的电影票打折方式，具体打折方案如下： (1) 学生凭学生证可享受票价 8 折优惠； (2) 年龄在 10 周岁及以下的儿童可享受每张票减免 10 元的优惠（原始票价需大于等于 20 元）； (3) 影院 VIP 用户除享受票价半价优惠外还可进行积分，积分累计到一定额度可换取电影院赠送的奖品。 该系统在将来可能还要根据需要引入新的打折方式 1.要满足开闭原则 二话不说先定义抽象类或接口 namespace StrategyTest { /// <summary> /// 抽象策略类 （折扣类） /// </summary> public interface IAbsStrategy { /// <summary> /// 打折 抽象方法（用拼音。。） /// </summary> /// <param name="price">价格</param> /// <returns>double</returns> double DaZhe(double price); } } 2.年龄在十岁以下-10元 namespace StrategyTest {

本系列博客是自己在学习设计模式过程中收集整理的文章集合，其他文章参看 设计模式传送门 本文是转载文章 ，原文请参见 设计模式（十二）——策略模式 概念 学习过设计模式的人大概都知道 Head First设计模式 这本书，这本书中介绍的第一个模式就是策略模式。把策略模式放在第一个，笔者认为主要有两个原因：1、这的确是一个比较简单的模式。2、这个模式可以充分的体现面向对象设计原则中的 封装变化 、 多用组合，少用继承 、 针对接口编程，不针对实现编程 等原则。 策略模式(Strategy Pattern)：定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化，也称为政策模式(Policy)。 用途 结合策略模式的概念，我们找一个实际的场景来理解一下。 假设我们是一家新开的书店，为了招揽顾客，我们推出会员服务，我们把店里的会员分为三种，分别是初级会员、中级会员和高级会员。针对不同级别的会员我们给予不同的优惠。初级会员买书我们不打折、中级会员买书我们打九折、高级会员买书我们打八折。 我们希望用户在付款的时候，只要刷一下书的条形码，会员再刷一下他的会员卡，收银台的工组人员就能直接知道应该向顾客收取多少钱。 在不使用模式的情况下，我们可以在结算的方法中使用 if/else 语句来区别出不同的会员来计算价格。 但是