创建一个能够根据所传递的参数对象的不同而具有不同行为的方法 要执行的算法固定不变,封装到一个类(Context)中 策略就是传递进去的参数对象,它包含执行代码 策略接口 /** * 策略接口 */ public interface IStrategy { String name(); /** * 具体逻辑(算法) * @param str * @return */ String Arithmetic(String str); } 具体实现 public class Downcase implem

Strategy是属于设计模式中 对象行为型模式,主要是定义一系列的算法,把这些算法一个个封装成单独的类. Stratrgy应用比较广泛,比如,公司经营业务变化图,可能有两种实现方式,一个是线条曲线,一个是框图(bar),这是两种算法,可以使用Strategy实现. 这里以字符串替代为例,有一个文件,我们需要读取后,希望替代其中相应的变量,然后输出.关于替代其中变量的方法可能有多种方法,这取决于用户的要求,所以我们要准备几套变量字符替代方案. 首先,我们建立一个抽象类RepTempRule 定义

策略模式是指定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换.本模式使得算法可独立于使用它的客户而变化.也就是说这些算法所完成的功能一样,对外的接口一样,只是各自实现上存在差异.用策略模式来封装算法,效果比较好. 本文以自己实际项目中策略模式的实际应用为例:实现无人驾驶车辆的定位有两种方式:GNSS(带差分信号的GPS)和SLAM,实现两种方法的定位可以视为采用两种不同的策略.定义抽象类locateStratey,再通过委托的方式将具体的算法实现委托给具体的Strategy类来实现.

刘备要到江东娶老婆了,走之前诸葛亮给赵云(伴郎)三个锦囊妙计,说是按天机拆开解决棘手问题,嘿,还别说,真是解决了大问题,搞到最后是周瑜陪了夫人又折兵呀,那咱们先看看这个场景是什么样子的. 先说这个场景中的要素:三个妙计,一个锦囊,一个赵云,妙计是小亮同志给的,妙计是放置在锦囊里,俗称就是锦囊妙计嘛,那赵云就是一个干活的人,从锦囊中取出妙计,执行,然后获胜,用 JAVA程序怎么表现这个呢?我们先看类图: 三个妙计是同一类型的东东,那咱就写个接口: package com.cbf4life.stra

概念:定义了一系列的算法,将每一种算法封装起来并可以相互替换使用,策略模式让算法独立于使用它的客户应用而独立变化. 接口抽象的就是某种方法. OO设计原则:1.面向接口编程  2.封装变化  3.多用组合,少用继承 public class Practice14 { public static void main(String[] args) { // TODO Auto-generated method stub //用父类的引用指向子类对象 Bird d=new BigBird("小白&qu

转载请注明出处:http://blog.csdn.net/lhy_ycu/article/details/39721563 今天開始咱们来谈谈Java设计模式. 这里会结合uml图形来解说,有对uml建模不熟的能够參考我的还有一篇博文uml建模. 首先.个人认为模式的设计就是一个将变化的东西和不变(稳定)的东西分离的过程. 咱们的应用中可能有非常多须要改变的地方,而模式要做的就是把它们"抽取"出来并进行"封装"和"实现",因此很多其它的时候咱们是

本文源码:GitHub·点这里 || GitEE·点这里 一.生活场景 每年双十一,各大电商平台会推出不同的满减策略,当用户的消费金额满一定额度后,会进行减去一定的优惠额度,从而来一波清仓甩卖,使用策略模式来描述该流程. public class C01_InScene { public static void main(String[] args) { // 选择满减策略,走相应的计算方式 FullReduce strategy = new Full100 (); Payment price

定义 定义一种算法,将每个算法都封装起来,并且使它们之间可以互换.是一种行为类模式. 举例 为了通俗易懂,我们拿各国的税率计算来举例子: 假设当前我们的程序只能支持计算中国和美国的税率: public class Tax_Cal { public int CN_Cal(int x) { // 计算中国税 } public int US_Cal(int x) { // 计算美国税 } } 这样写看起来没什么问题,但实际上我们想想,如果以后公司还要拓展,开始支持法国,日本等等国家,那么我们这个类就得

策略模式:定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户. 1,定义算法接口 package com.pattern.strategy.test; public interface MoveBehavior { public void move(); } 2,定义算法的实现类 下面是三个算法的实现类 a, MoveFastBehavior package com.pattern.strategy.test; public class MoveFastB

(十三)策略模式 策略图案限定了多个封装算法,该算法可以相互替换包.法的客户.借用还有一位大神的样例. interface ICalculator{ public int calculate(String exp); } abstract class AbstractCalculator{ public int[] split(String exp,String opt){ String array[] = exp.split(opt); int arrayInt[] = new int[2];

一.概述 定义:策略模式是指对一系列的算法定义,并将每一个算法封装起来,而且使它们还可以相互替换.策略模式让算法独立于使用它的客户而独立变化.(概念不好理解,可以看第二节的合例子) 基本角色: 环境(Context)角色:持有一个Strategy的引用,并执行策略的方法. 抽象策略(Strategy)角色:这是一个抽象角色,通常由一个接口或抽象类实现.此角色给出所有的具体策略类所需的接口. 具体策略(ConcreteStrategy)角色:包装了相关的算法或行为 二.示例 举个实际场景:一个老板

适用于同一操作的不同行为,策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们可以相互替换,让算法独立于使用它的客户而独立变化,具体应用场景如第三方支付对接不同银行的算法. 要点:1)抽象策略角色    2)具体策略角色:包装相关算法和行为 3)环境角色:持有一个策略类的引用,最终给客户端调用 1.抽象策略接口 public interface SwimmingStratege { public void swimming(); } 2.具体策略角色SwimmingWithFoot p

0.假设现有工程(Duck)中遇到为类添加功能的问题,如何设计类添加新的功能? 1.利用继承提供的Duck(鸭子)的行为会导致哪些缺点? (1)代码在多个子类中重复 (2)很多男知道所有鸭子的全部行为 (3)运行时的行为不容易改变 (4)改变会牵一发动全身,造成其他鸭子的不想要的改变 [设计原则] 找出应用中可能需要变化之处,把它们独立出来,不要和那些不需呀变化的代码混在一起 2.分开变化与不会变化的部分 将Duck分成两部分,鸭子类和鸭子行为. 类的固有属性和共用的方法写在类中,行为另起一个类

按一般教程中出现的例子理解: 简单工厂模式:客户端传一个条件进工厂类,工厂类根据条件创建相应的产品类对象,并return给客户端,供客户端使用.即客户端使用的是工厂类生产的产品对象. 策略模式:客户端创建一个Context类对象a(可以看作是工厂模式中工厂类),创建一个策略对象并传参给对象a,然后客户端使用a对象的某些方法来使用前面传参进来的策略,即客户端是通过a对象使用策略的. 简单的说, 1.工厂模式根据条件生产出产品给客户端用.而策略模式是客户端使用传参给Context的策略(你也可以理成

Command模式是最让我疑惑的一个模式,我在阅读了很多代码后,才感觉隐约掌握其大概原理,我认为理解设计模式最主要是掌握起原理构造,这样才对自己实际编程有指导作用.Command模式实际上不是个很具体,规定很多的模式,正是这个灵活性,让人有些confuse. Command定义 不少Command模式的代码都是针对图形界面的,它实际就是菜单命令,我们在一个下拉菜单选择一个命令时,然后会执行一些动作. 将这些命令封装成在一个类中,然后用户(调用者)再对这个类进行操作,这就是Command模式,换句

Visitor定义:作用于某个对象群中各个对象的操作.它可以使你在不改变这些对象本身的情况下,定义作用于这些对象的新操作. 在Java中,Visitor模式实际上是分离了collection结构中的元素和对这些元素进行操作的行为. 为何使用Visitor模式 Java的Collection(包括Vector和Hashtable)是我们最经常使用的技术,可是Collection好象是个黑色大染缸,本来有各种鲜明类型特征的对象一旦放入后,再取出时,这些类型就消失了.那么我们势必要用If来判断,如:

State的定义:不同的状态,不同的行为:或者说,每个状态有着相应的行为. 何时使用状态模式 State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了. 不只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数据库系统中出现频率比较高,我们经常会在一个数据表的尾部,加上property属性含义的字段,用以标识记录中一些特殊

Mediator定义:用一个中介对象来封装一系列关于对象交互行为. 为何使用Mediator模式/中介模式 各个对象之间的交互操作非常多,每个对象的行为操作都依赖彼此对方,修改一个对象的行为,同时会涉及到修改很多其他对象的行为,如果使用Mediator模式,可以使各个对象间的耦合松散,只需关心和 Mediator的关系,使多对多的关系变成了一对多的关系,可以降低系统的复杂性,提高可修改扩展性. 如何使用中介模式 首先 有一个接口,用来定义成员对象之间的交互联系方式:    public inte

Memento定义:memento是一个保存另外一个对象内部状态拷贝的对象,这样以后就可以将该对象恢复到原先保存的状态. Memento模式相对也比较好理解,我们看下列代码: public class Originator { private int number; private File file = null; public Originator(){} // 创建一个Memento public Memento getMemento(){ return new Memento(this)

上了这么多年学,我发现一个问题,好象老师都很喜欢点名,甚至点名都成了某些老师的嗜好,一日不点名,就饭吃不香,觉睡不好似的,我就觉得很奇怪,你的课要是讲的好,同学又怎么会不来听课呢,殊不知:“误人子弟,乃是犯罪!”啊. 好了,那么我们现在来看老师这个点名过程是如何实现吧:1.老规矩,我们先定义老师(Teacher)接口类: public interface Teacher { public Iterator createIterator(); //点名 } 2.具体的老师(ConcreteTeac

外观模式(Facade)的定义:为子系统中的一组接口提供一个一致的界面. Facade一个典型应用就是数据库JDBC的应用,如下例对数据库的操作: public class DBCompare { Connection conn = null; PreparedStatement prep = null; ResultSet rset = null; try { Class.forName( "<driver>" ).newInstance(); conn = Driver