策略模式

装饰模式 装饰器模式，也成为包装模式，顾名思义，就是对已经存在的某些类进行装饰，以此来扩展一些功能。其结构图如下： 　 Component为统一接口，也是装饰类和被装饰类的基本类型。 ConcreteComponent为具体实现类，也是被装饰类，他本身是个具有一些功能的完整的类。 Decorator是装饰类，实现了Component接口的同时还在内部维护了一个ConcreteComponent的实例，并可以通过构造函数初始化。而Decorator本身，通常采用默认实现，他的存在仅仅是一个声明：我要生产出一些用于装饰的子类了。而其子类才是赋有具体装饰效果的装饰产品类。 ConcreteDecorator是具体的装饰产品类，每一种装饰产品都具有特定的装饰效果。可以通过构造器声明装饰哪种类型的ConcreteComponent，从而对其进行装饰。 //房屋基础接口 public interface House { void run(); } //房屋装饰类 public class HouseDecorate implements House { private House house; public HouseDecorate(House house){ this.house=house; } @Override public void run() { house.run();

多网卡的7种bond模式原理 Linux 多网卡绑定 网卡绑定 mode 共有七种 (0~6) bond0 、 bond1 、 bond2 、 bond3 、 bond4 、 bond5 、 bond6 常用的有三种 mode=0 ：平衡负载模式，有自动备援，但需要” Switch ”支援及设定。 mode=1 ：自动备援模式，其中一条线若断线，其他线路将会自动备援。 mode=6 ：平衡负载模式，有自动备援，不必” Switch ”支援及设定。 需要说明的是如果想做成 mode 0 的负载均衡 , 仅仅设置这里 options bond0 miimon=100 mode=0 是不够的 , 与网卡相连的交换机必须做特殊配置（这两个端口应该采取聚合方式），因为做 bonding 的这两块网卡是使用同一个 MAC 地址 . 从原理分析一下（ bond 运行在 mode 0 下）： mode 0 下 bond 所绑定的网卡的 IP 都被修改成相同的 mac 地址，如果这些网卡都被接在同一个交换机，那么交换机的 arp 表里这个 mac 地址对应的端口就有多 个，那么交换机接受到发往这个 mac 地址的包应该往哪个端口转发呢？正常情况下 mac 地址是全球唯一的，一个 mac 地址对应多个端口肯定使交换机迷惑了。所以 mode0 下的 bond 如果连接到交换机

import java.util.HashMap; public class XuQiu { /** * 策略模式构建当池子中包含某个元素的时候，执行池子元素+1 * 池子不包含某种元素的时候，给池子中添加元素 * 分析：两种动作，给池子中的元素+1， 给池子中添加元素,值为1 * 本人对策略模式的理解：主要解决的是行为【算法】的使用者 和 行为【算法】 本身的解耦合 * 本例中XuQiu类是行为【算法】的使用者，而 Action接口及其子类是行为【算法】本身 * 优点：结构清晰，适当符合开闭原则：假如又来一种情况，只需要增加action子类和修改响应的调用，而不用动调用者这一层了 * 优点2: 便于将action对象优化为单例，这样效率一点也没有影响，只用new一次。 * 缺点：多new了对象。 * */ public static HashMap<String,Integer> poll; public static void main(String[] args) { poll=new HashMap(); String key="usdt"; for(int i=0;i<=5;i++){ Action1.getInstance().add(poll,key); System.out.println(poll); } } } ================行为在下面====

　　最近系统需要对不同维度的数据进行差异化计算，也就会使用不同算法。为了以后更加容易扩展，结合Spring框架及策略模式对实现架构做了系统设计。 1. 定义策略接口（Strategy）： import com.dmall.scfc.biz.dao.model.ScfcScoreField; import com.dmall.scfc.biz.dao.model.ScfcScoreFieldValue; import com.dmall.scfc.biz.dto.ScoreModelDimensionDTO; import java.util.List; /** * @author wangxuexing * @descrption 数据抽取策略 * @date 2019/12/4 */ public interface Strategy { /** * 是否匹配策略 * @param scoreField 基础字段 * @return */ boolean isMatch(ScfcScoreField scoreField); /** * 根据具体字段抽取数据 * @param dimensionRule * @return */ List<ScfcScoreFieldValue> extractData(ScoreModelDimensionDTO dimensionRule)

前言 # 物流行业中，通常会涉及到EDI报文(XML格式文件)传输和回执接收，每发送一份EDI报文，后续都会收到与之关联的回执（标识该数据在第三方系统中的流转状态）。这里枚举几种回执类型： MT1101、MT2101、MT4101、MT8104、MT8105、MT9999 ，系统在收到不同的回执报文后，会执行对应的业务逻辑处理。当然，实际业务场景并没有那么笼统，这里以 回执处理为演示案例 模拟一个回执类 Copy ``@Data public class Receipt { /** * 回执信息 */ String message; /** * 回执类型(`MT1101、MT2101、MT4101、MT8104、MT8105、MT9999`) */ String type; }`` 模拟一个回执生成器 Copy `public class ReceiptBuilder { public static List<Receipt> generateReceiptList(){ //直接模拟一堆回执对象 List<Receipt> receiptList = new ArrayList<>(); receiptList.add(new Receipt("我是MT2101回执喔","MT2101")); receiptList.add(new Receipt("我是MT1101回执喔",

最近工作比较忙，一直没有时间来写文章，今天就简单的写下策略模式。 今天要实现的是一个商场收银软件，当然首先我们会采用上期讲的用简单工厂模式来实现，其具体的实现参考代码 http://download.csdn.net/detail/txtfashion/5078259 ： 那么用简单工厂模式来实现存在什么缺陷呢，因为商场经常性地更改打折额度和返利额度，每次维护或扩展收费方式读要改动这个工厂，以致代码需要重新编译。因此我们需要找到一种适应算法经常改动的模式。下面就要引出策略模式。 策略模式是一组算法，将每个算法都封装起来，并且使他们之间可以互换。此模式让算法的变化，不会影响到使用算法的客户。 策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少算法类与使用算法类之间的耦合。 策略模式的Strategy类层为Context定义了一系列的可重用的算法或行为，继承有足浴析取这些算法中的公共功能。另外，它简化了单元测试，因为每个算法独有自己的类，可以通过自己的接口单独测试。 策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的行为，只要在分析过程中听到需要在不同时间应用不同业务规则，就可以考虑使用策略模式处理这种变化的可能性。但基本的策略模式中，选择用具体的实现的职责有客户端对象承担

第二章 商场促销-策略模式 1.1简单工厂实例 现在我们需要为某大型超市设计一个收银软件,收银员根据顾客购买的商品的单价和数量,向顾客收费 根据我们之前学到的简单工厂模式,我们可以这样做 代码结构图如下: 抽象产品Product角色CashSuper package dp02Strategy; public abstract class CashSuper { //现金收取超类的抽象方法，收取现金，参数为原价，返回当前价 public abstract double acceptCash(double money); } 具体Product角色之正常收费类CashNormal package dp02Strategy; public class CashNormal extends CashSuper{ public double acceptCash(double money) { return money; } } 具体Product角色之打折收费类CashRebate package dp02Strategy; public class CashRebate extends CashSuper{ //暂定打折率为1 private double moneyRebate=1d; CashRebate(double moneyRebate){ this.moneyRebate

引入问题：要实现一个商场收费软件，根据单价，数量来向客户收费，其中收费方式可以有多种（变化多）。 方法一：简单工厂模式实现 一个CashSuper类统一接口，多个具体的计算类继承于CashSuper类，一个工厂方法CashFactory创建具体实现类。 //现金收费抽象类 abstract class CashSuper { public abstract double acceptCash(double money); } //正常收费 class CashNormal : CashSuper { public override double acceptCash(double money) { return money; } } //打折收费类 class CashRebate:CashSuper { private double moneyRebate = 1d; public CashRebate(String moneyRebate) { this.moneyRebate = double.Parse(moneyRebate); } public override double acceptCash(double money) { return moneyRebate*money; } } //返利收费 class CashReturn:CashSuper {

　　面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。 　　在说策略模式之前，我们想用简单工厂模式来实现商场收银程序 #include <iostream> using namespace std; //现金收费抽象类 class CashSuper { public: virtual double acceptCash(double money)=0; }; //正常收费子类 class CashNormal:public CashSuper { public: double acceptCash(double money) { return money; } }; //打折收费子类 class CashRebate:public CashSuper { private: double moneyRebate; public: CashRebate(double moneyRebate) { this->moneyRebate=moneyRebate; } double acceptCash(double money) { return money*moneyRebate; } }; //返利收费子类 class CashReturn:public CashSuper { private: double

文章目录 一、概念 二、动机 三、源代码讲解 四、使用策略模式进行改进 五、类图结构 六、要点总结 一、概念    定义一系列算法，把他们一个个封装起来，并且使他们可以互相替换（变化<各个算法>） 。该模式使得算法可独立于使用它的客户程序（稳定<SalesOrder类>）而变化（扩展，子类化）。——《设计模式》GOF 二、动机    在软件构建过程中， 某些对象可能用到的算法多种多样，经常改变，如果将这些算法都编码到对象中，将会使得对象变得异常复杂 ；而且有时候支持不使用的算法也是一个性能负担。    如何在运行时根据需要透明地更改对象的算法？ 将算法与对象本身解耦 ，从而避免上述问题？ 三、源代码讲解 enum TaxBase { CN_Tax , US_Tax , DE_Tax , FR_Tax // 更改 } ; class SalesOrder { TaxBase tax ; public : double CalculateTax ( ) { //... if ( tax == CN_Tax ) { //CN*********** } else if ( tax == US_Tax ) { //US*********** } else if ( tax == DE_Tax ) { //DE*********** } else if ( tax == FR_Tax ) {