策略模式

在阎宏博士的《JAVA与模式》一书中开头是这样描述策略（Strategy）模式的： 　　 策略模式属于对象的行为模式。其用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。 策略模式的结构 　　策略模式是对算法的包装，是把使用算法的责任和算法本身分割开来，委派给不同的对象管理。策略模式通常把一个系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是：“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。下面就以一个示意性的实现讲解策略模式实例的结构。 　　这个模式涉及到三个角色： 　　●　　 环境(Context)角色： 持有一个Strategy的引用。 　　●　　 抽象策略(Strategy)角色： 这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。 　　●　　 具体策略(ConcreteStrategy)角色： 包装了相关的算法或行为。 源代码 　　环境角色类 public class Context { //持有一个具体策略的对象 private Strategy strategy; /** * 构造函数，传入一个具体策略对象 * @param strategy 具体策略对象 */ public Context

策略模式和工厂模式的搭配使用可以很好地消除代码 if-else 的多层嵌套 需求 针对店下商铺，有这样一个需求，对用户客户分为了普通客户、 vip 客户、超级 vip 用户、专属 vip 用户 4 个等级，每当用户购买商品时，针对不同的用户等级和消费金额采取不同的打折优惠策略。在平常的开发当中，必然会出现多层的 if-else 嵌套判断，先判断用户的等级再判断用户购买商品的消费金额。 弊端 以上的情况出现了多层的 if-else 嵌套，除此之外，以后如果需求再有变动，需要再增加一个用户等级，那么又会再次添加 if-else 的嵌套判断，那么如何解决上述的弊端呢，采用策略模式和工厂模式的搭配使用，可以很好地优化多层 if-else 的多层嵌套 实现 编写用户等级枚举类 java">package com.zbiti.ifelse.UserType; /** * 用户类型枚举类 */ public enum UserPayServiceEnum { VIP(1,"Vip"), SUPERVIP(2,"SuperVip"), PARTICULALYVIP(3,"ParticularlyVip"), NORMAL(4,"NormalPayService"); /** * 状态值 */ private int code; /** * 类型描述 */ private String value;

策略模式和工厂模式的搭配使用可以很好地消除代码 if-else 的多层嵌套 需求 针对店下商铺，有这样一个需求，对用户客户分为了普通客户、 vip 客户、超级 vip 用户、专属 vip 用户 4 个等级，每当用户购买商品时，针对不同的用户等级和消费金额采取不同的打折优惠策略。在平常的开发当中，必然会出现多层的 if-else 嵌套判断，先判断用户的等级再判断用户购买商品的消费金额。 弊端 以上的情况出现了多层的 if-else 嵌套，除此之外，以后如果需求再有变动，需要再增加一个用户等级，那么又会再次添加 if-else 的嵌套判断，那么如何解决上述的弊端呢，采用策略模式和工厂模式的搭配使用，可以很好地优化多层 if-else 的多层嵌套 实现 编写用户等级枚举类 package com.zbiti.ifelse.UserType; /** * 用户类型枚举类 */ public enum UserPayServiceEnum { VIP(1,"Vip"), SUPERVIP(2,"SuperVip"), PARTICULALYVIP(3,"ParticularlyVip"), NORMAL(4,"NormalPayService"); /** * 状态值 */ private int code; /** * 类型描述 */ private String value;

策略模式 定义 所谓策略模式就是定义了算法族，分别封装起来，让他们之前可以互相转换，此模式然该算法的变化独立于使用算法的客户 理解 策略这个词应该怎么理解，打个比方说，我们出门的时候会选择不同的出行方式，比如骑自行车、坐公交、坐火车、坐飞机、坐火箭等等，这些出行方式，每一种都是一个策略 再比如我们去逛商场，商场现在正在搞活动，有打折的、有满减的、有返利的等等，其实不管商场如何进行促销，说到底都是一些算法，这些算法本身只是一种策略，并且这些算法是随时都可能互相替换的，比如针对同一件商品，今天打八折、明天满100减30，这些策略间是可以互换的 UML类图 其中，Context是上下文，用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用；Strategy是策略类，用于定义所有支持算法的公共接口；ConcreteStrategy是具体策略类，封装了具体的算法或行为，继承于Strategy 解释 1.Context 上下文 Context上下文角色，也叫Context封装角色，起承上启下的作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化 public class Context { Strategy strategy; public Context(Strategy strategy){ this.strategy = strategy; } /*

首先谈谈自己对策略模式的理解： 假如业务需求中需要根据不同的任务种类（假设A B等等）作出不同的处理方式，我们是否要采用if else的方式，逐个判断呢？ if(type=="A"){ //A的处理逻辑 }else if(type=="B"){ //B的处理逻辑 }//........ 以上写法实现功能自然没有问题，但是随着任务种类的增加，我们需要不停的添加或者修改if else判断语句，以及添加或修改相应的处理逻辑，方法也会非常臃肿，亦不符合面向对象的对修改关闭，对拓展开放的原则。 由此，引入策略模式来解决这个问题。 以下是我简单模拟的一个策略模式的代码轮廓，实际应用可能要复杂一些，只表明策略模式的思想： 忘记是参考的哪篇博客了..... Handle接口，作为任务处理器的一个简单抽象，定义来返回类型接口 getType 和 处理任务方法 process ， 所有的任务处理类都实现Handle接口，根据不同的类型，对应不同的处理逻辑 TypeEnums 枚举则作为任务类型定义所有的任务种类 public interface Handle<T> { /** * 处理方法 * @param t */ void process(T t); /** * 获取类型 */ TypeEnums getType(); } public enum TypeEnums { TYPEA("A",

最近本来想优化一个单查为批量查询，然后一顿侧滑之后，反而改了下别人策略的实现，具体的工厂方法实现如下： @Component public class TestFactory implements InitializingBean, ApplicationContextAware { private ApplicationContext applicationContext; public static Map<TestEnum, AbstractConsignTab> strategyMap = Maps.newConcurrentMap(); @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } @Override public void afterPropertiesSet(){ Map<String, AbstractConsignTab> childList = applicationContext.getBeansOfType(AbstractTestTab.class); for (Map.Entry<String,

策略模式 一、策略模式简介 先看一下示例，假如一个超市，在结账的时候对不同的会员进行不同的打折策略，该代码实现如下 抽象会员接口 public interface VIPCard { double sale(double money); } 普通会员不打折 public class CommonVip implements VIPCard { @Override public double sale(double money) { return 1 * money; } } 黄金会员打九折 public class GoldVip implements VIPCard{ @Override public double sale(double money) { return 0.9 * money; } } 钻石会员打八折 public class DiamondVip implements VIPCard { @Override public double sale(double money) { return 0.8 * money; } } 具体环境，超市打折计算金额 public class Shop{ private VIPCard vipCard; public Shop(VIPCard vipCard){ this.vipCard=vipCard; } public

策略模式 1、策略模式介绍 实现某一个功能可以有多种算法或者策略，我们根据实际情况选择不同的算法或者策略完成该功能，一般就会用if…else或者switch…case语句来选择具体算法，需要增加一种新的排序算法时，需要修改封装算法类的源代码，违背了ocp原则和单一职责原则，将这些算法抽象出来提供一个统一的接口，不同算法有不同的实现类，让算法独立于使用它的客户而独立 2、策略模式的使用场景 （1）针对同一类型问题的多种处理方式，仅仅是具体行为有差别时 （2）需要安全地封装多种同一类型的操作时 （3）出现同一个抽象类有多个子类，又需要if…else switch-case选择具体子类时 3、策略模式的简单实现 建立一个策略的抽象，让具体的策略实现实现这个接口，Context则可以充当操作策略的上下文环境 一下例子为价格计算策略，它们都实现了calculatePrice这个接口的方法 以下代码为扮演Context角色的类 public class TranficCalculator { public static void main ( String [] args ){ TranficCalculator calculator = new TranficCalculator () calculator . setStrategy ( new BusStrategy (); }

一：bonding的概念 所谓bonding就是将多块网卡绑定同一IP地址对外提供服务，可以实现网卡的带宽扩容、高可用或者负载均衡。 二：bonding的优势 1 网络负载均衡 2 提高带宽网络传输效率 3 网络冗余与高可用 三：bonding的策略(7种策略) 1 balance-rr （mode=0）轮询（Round-robin）策略：从头到尾顺序的在每一个slave接口上面发送数据包。本模式提供负载均衡和容错的能力。 2 active-backup（mode=1）主备模式 ,在绑定中，只有一个slave被激活。当且仅当活动的slave接口失败时才会激活其他slave。为了避免交换　　机发生混乱此时绑定的MAC地址只有一个外部端口上可见。在bongding的2.6.2及其以后的版本中，主备模式下发生一次故障迁移时，bonding将在新　　激活的slave上会送一个或者多个gratuitous ARP.bonding的主salve接口上以及配置在接口上的所有VLAN接口都会发送gratuitous ARP，只要　　这些接口上配置了至少一个IP地址。VLAN接口上发送的的gratuitous ARP将会附上适当的VLAN id。本模式提供容错能力，primary option，　　documented below会影响本模式的行为。 3 balance-xor（mode=2

一、 Spring 中常见的设计模式 工厂模式 ： BeanFactory 装饰器模式： BeanWrapper 代理模式： AopProxy 单例模式： ApplicationContext 委派模式： DispatcherServlet 策略模式: HandlerMapping 适配器模式： HandlerApdapter 模板方法模式： JdbcTemplate 观察者模式： ContextLoaderListener 二、Spring 的四大模块及典型的 设计模式 　　4、Spring JDBC 模板方法模式