重构没有固定的形式,多年来我使用过不同的版本,并且我敢打赌不同的人也会有不同的版本. 该重构适用于这样的场景:switch语句块很大,并且会随时引入新的判断条件.这时,最好使用策略模式将每个条件封装到单独的类中.实现策略模式的方式是很多的.我在这里介绍的策略重构使用的是字典策略,这么做的好处是调用者不必修改原来的代码. public class ClientCode { public double CalculateShipping() { ShippingInfo shippingInfo =

理解javascript中的策略模式 策略模式的定义是:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换. 使用策略模式的优点如下: 优点:1. 策略模式利用组合,委托等技术和思想,有效的避免很多if条件语句. 2. 策略模式提供了开放-封闭原则,使代码更容易理解和扩展. 3. 策略模式中的代码可以复用. 一:使用策略模式计算奖金: 下面的demo是我在书上看到的,但是没有关系,我们只是来理解下策略模式的使用而已,我们可以使用策略模式来计算奖金问题: 比如公司的年终奖是根据员工的工

策略模式是oop中最著名的设计模式之一,是对方法行为的抽象,可以归类为行为设计模式,也是oop中interface经典的应用.其特点简单又实用,是我最喜欢的模式之一.策略模式定义了一个拥有共同行为的算法族,每个算法都被封装起来,可以互相替换,独立于客户端而变化.策略模式本身的实现比较简单,但是结合单例模式+简单工厂模式+注解+反射,可以构造出近乎完善的策略模式,彻底的消除if-else. 一.策略模式基础 策略模式是oop中最著名的设计模式之一,是对方法行为的抽象,可以归类为行为设计模式,也是o

目录 1.背景 2.案例 3.switch…case…方式实现 4.switch…case…带来的问题 5.使用策略模式重构switch…case…代码 6.总结 1.背景 之前在看<重构    改善既有代码的设计>一书,在看到Replace Type Code With  State/Strategy(用状态模式/策略模式替换类型码)一节时遇到一个困惑:怎么用策略模式替换switch case代码?所幸的时,两天前查资料的时候偶然看到 圣殿骑士 的博客,他写的<31天重构学习>系

我这里的业务场景是根据消息类型将离线消息存入mongoDB不同的collection中.其中就涉及到大量的分支判断,为了增强代码的可读性和可维护性,对之前的代码进行了重构. 先对比一下使用反射+策略模式前后的代码: 重构前: 重构后: 我们可以看到重构前的代码充斥着大量的分支判断,以后每增加一个新的消息类型就要增加一个新的具体实现类和增加一个新的分支判断,可拓展性是相当差的:而重构后的代码当需要增加一个新的消息类型时,只需要增加一个具体的实现类就可以实现,根本不需要考虑分支判断,这也是我们希望看

名词:类型码 类型码的上层建筑 重构方法 1.使用子类代替类型码 2.使用状态/策略模式代替类型码 类中存在方法把某个字段当作条件,根据字段值的不同,进行不同的处理.(自定义概念)则这个字段叫做:类型码.(重构-改善既有代码的设计中的概念)这个方法叫做:类型码的上层建筑.(自定义概念)(这种判断方法不是绝对正确,但是一般可行,类型码是重构-改善既有代码的设计的概念,但是类型码的上层建筑是自定义概念) 例子1:Movie对象中存在影片类型字段,根据影片类型和租期计算金额的getCharge()方法

最近在工作中优化了一段冗余的if else代码块,感觉对设计模式的理解和运用很有帮助,所以分享出来.鉴于原代码会涉及到公司的隐私,因此就不贴出来了.下面以更加通俗易懂的案例来解析. 假如写一个针对员工上班不遵守制度做相应惩罚的程序,比如,上班迟到:罚100:上班睡觉:罚1000:上班早退:警告:上班玩游戏:严重警告:上班谈恋爱:开除等,通常都会这样写: public class WorkPunish { public static void main(String[] agrs){ String

最近在工作中优化了一段冗余的if else代码块,感觉对设计模式的理解和运用很有帮助,所以分享出来.鉴于原代码会涉及到公司的隐私,因此就不贴出来了.下面以更加通俗易懂的案例来解析. 假如写一个针对员工上班不遵守制度做相应惩罚的程序,比如,上班迟到:罚100:上班睡觉:罚1000:上班早退:警告:上班玩游戏:严重警告:上班谈恋爱:开除等,通常都会这样写: public class WorkPunish { public static void main(String[] agrs){ String

前言 当代码中出现多重if-else语句或者switch语句时.弊端之一:如果这样的代码出现在多处,那么一旦出现需求变更,就需要把所有地方的if-else或者switch代码进行更改,要是遗漏了某一处,那么程序就会出错.弊端之二:代码逻辑难以理解. 卫语句 卫语句的使用,并不能改变前言说的弊端:一旦需求更改,需要修改所有使用更改需求的if-else代码块.不过使用卫语句可以让自己或者代码维护人员很容易的了解代码的含义. 代替异常分支 所谓的异常分支就是普通情况之外的分支,这种情况的下的if-el

前言 当代码中出现多重if-else语句或者switch语句时.弊端之一:如果这样的代码出现在多处,那么一旦出现需求变更,就需要把所有地方的if-else或者switch代码进行更改,要是遗漏了某一处,那么程序就会出错.弊端之二:代码逻辑难以理解. 卫语句 卫语句的使用,并不能改变前言说的弊端:一旦需求更改,需要修改所有使用更改需求的if-else代码块.不过使用卫语句可以让自己或者代码维护人员很容易的了解代码的含义. 代替异常分支 所谓的异常分支就是普通情况之外的分支,这种情况的下的if-el

最近完成了我们公司的公众号开发,在微信消息路由选择的时候一开始都是用if-else 来判断,后面if-else月写越多显得十分的乱.在网上简单查了一下解决方法,果然有不少干货,感觉最经典最简洁的还是使用策略模式来重构过多的if-else 选择. 首先我们新建一个interface public interface InnerCommand { void process(String msg); }   然后把每一个if逻辑都单独抽取到一个类里面如 /** * @author lee. * @da

1.传统if -else 写法 String nodeModelStr = ""; if (nodeType == NodeType.START){ StartModel startModel = JSON.parseObject(nodeModelStr,StartModel.class) }else if(nodeType == NodeType.END){ EndModel endModel = JSON.parseObject(nodeModelStr,EndModel.cla

模式动机 完成一项任务,往往可以有多种不同的方式,每一种方式称为一个策略,我们可以根据环境或者条件的不同选择不同的策略来完成该项任务.在软件开发中也常常遇到类似的情况,实现某一个功能有多个途径,此时可以使用一种设计模式来使得系统可以灵活地选择解决途径,也能够方便地增加新的解决途径. 在软件系统中,有许多算法可以实现某一功能,如查找.排序等,一种常用的方法是硬编码(Hard Coding)在一个类中,如需要提供多种查找算法,可以将这些算法写到一个类中,在该类中提供多个方法,每一个方法对应一个具体的

一.问题 模拟不同课程有不同的收费方式,并且能灵活改变(新增或删减),如讲座可以固定收费也可改为按时收费,研讨会也是. 二.模式简介及关键点 1.在父类代码中使用条件语句是一种退倒,可以用多态来代替条件语句.条件语句有时被称作实现了一个“模拟继承” 2.策略模式适用于将一组算法移入到一个独立的类型中.如例子通过移走费用计算的相关代码,可以简化Lesson类型 3.在合理的模式中,Lesson类不负责计费,而是把计费任务“委托”给CostStrategy类.这种显式调用另一个对象的方法来执行一个请

一.前言 关于设计模式的文章,园子里实在是太多太多,而且讲解的也非常精彩,那为什么我还要在这里记录下这篇文章?本文以实际项目应用“自己动手写工具--XSmartNote”为切入点,来讲述策略模式的应用.很多初学者都有一种感觉,就是在看设计模式相关文章的时候,都看得懂,而且小Demo也是手到擒来,但是就是不知道该怎么用在实际的项目中,不管你之前有没有过这种感觉,反正我是曾经有过.在前几天Review Code的时候发现XSmartNote中的主题管理功能很适合这种模式,于是就把这块相关的代码重构了

学习设计模式已经有非常长一段时间了,事实上先前已经敲过一遍了.可是老认为没有学到什么,认识也不够深刻.如今趁着重构机房,再又一次来过,也不晚. 事实上在敲了机房之后,看看模式,事实上,曾经非常难理解.非常难看懂的代码一眼就能够看懂了,趁着有点感觉了.早点收获吧. 简单工厂模式: 简单地说简单工厂模式:非常easy变化的地方,就能够用到简单工厂模式. 实例: 举个样例:我们在逛商场时.正好商场促销,各种优惠活动:有满300返100 ,有打8折的.抽奖等等吧. 促销来讲,各种优惠活动事实上就是变化.

策略模式的定义: 将算法一个个的单独进行封装,并且使他们可以相互替换.此模式让算法的变化不会影响到使用算法的客户. 先回顾一下,我们在做项目的过程中,是不是经常会遇见因为业务逻辑的关系,我们会写好多的is-else语句进行判断,或者使用switch语句,在后期添加新的需求的时候,比较头疼的需要去改这些判断语句,而且有时候会,添加一条判断语句,一不小心会导致所有的判断都失效呢?举一个之前项目中用到的例子把,简化一下.有一个按钮在不同的条件下,跳转到不同的页面,如下: toseeHouse() {

策略模式是GoF23种设计模式中比较简单的了,也是常用的设计模式之一,今天我们就来看看策略模式. 实际案例 我工作第三年的时候,重构旅游路线的机票查询模块,旅游路线分为四种情况: 如果A地-B地往返都可以直达,那么查询两张机票(往返) 如果A地-B地去程无法直达,需要中转,但是返程可以直达,那么查询三张机票(去程两张,返程一张) 如果A地-B地去程可以直达,但是返程需要中转,那么查询三张机票(去程一张,返程两张) 如果A地-B地往返都无法直达,那么查询四张机票(去程两张,返程两张) 在我重构前,

前言: 最近一直在学习基于okHttp网络请求,学习的过程中就想起了之前项目中有这么一个需求不同的接口要采用不同的加密方式,比如登录之前要采用RSA加密,登录之后要采用AES加密,当时是采用靠传递一个参数过去来对参数进行不同的加密算法,这样会让代码难以维护而且难以扩展,那该如何解决呢?今天来学习一下策略模式Strategy!用它来解决这个问题. 策略模式:        策略模式属于对象的行为模式.其用意是针对一组算法,将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换.策略模

在前段时间呢陆陆续续的更新了一系列关于重构的文章.在重构我们既有的代码时,往往会用到设计模式.在之前重构系列的博客中,我们在重构时用到了“工厂模式”.“策略模式”.“状态模式”等.当然在重构时,有的地方没有点明使用的是那种设计模式.从今天开始,我们就围绕着设计模式这个主题来讨论一下我们常用的设计模式,当然“GoF”的23种设计模式不会全部涉及到,会介绍一些常见的设计模式.在接下来我们要分享的设计模式这个系列博客中,还是以Swift语言为主来实现每种设计模式的Demo.并且仍然会在GitHub上进