if else 太多了 最近跟着公司的大佬开发了一款IM系统,类似QQ和微信哈,就是聊天软件。...我们有一部分业务逻辑是这样的 if (msgType = "文本") { // dosomething } else if(msgType = "图片") { // doshomething...} else if(msgType = "视频") { // doshomething } else { // doshomething } 就是根据消息的不同类型有不同的处理策略...,每种消息的处理策略代码都很长,如果都放在这种if else代码快中,代码很难维护也很丑,所以我们一开始就用了策略模式来处理这种情况。
原文链接:https://pdai.tech/md/develop/refactor/dev-refactor-if-else.html 最为常见的是代码中使用很多的if/else,或者switch/...case;如何重构呢?...方法特别多 出现if/else和switch/case的场景 重构思路 方式一 - 工厂类 方式二 - 枚举 方法三 - 命令模式 方法四 - 规则引擎 方法五 - 策略模式 一些反思 出现if/else...重构思路 有非常多的重构方法来解决这个问题, 这里会列举很多方法,在实际应用中可能会根据场景进行一些调整;另外不要纠结这些例子中显而易见的缺陷(比如没用常量,没考虑多线程等等),而是把重心放在学习其中的思路上...真的要这么重构吗?
上次那篇重构-为什么 if-else 不是好代码 说到代码中的 if-else会随着代码量的增加,在迭代的过程中变的越来越难以维护, 然后用工厂模式的思路可以把 if-else代码块给剥离开来, 不过有朋友提出了不足.... } else if (target.contains("#")) { .... } else { .... } } } 开始重构...private static HashMap mMappings = new HashMap(); 而判断 target内容的逻辑也不需要放在工厂类里了,可以重构...pattern)) { return mMappings.get(pattern); } } } } 这只是一种代码中的小技巧,可以在重构代码的时候让整个代码逻辑清晰很多...对于这种情况上面的重构方法就没那么好了, 所以我习惯的话会把 if-else 剥离到工厂中就结束,但如果涉及到多个模块的人之间的合作的话, 才会再拆分一层,让大家自己把自己的 executor 在静态方法块中注册到
如何重构掉这段代码 对于这种代码我们重构的目标可以有两个深度,看自己强迫症的严重程度决定 · 继续用 if-else,只达到剥离执行代码块 · 用工厂模式去耦合 对于这两种其实不是非此即彼的关系,而是优化深度不同...第一种相对比较简单,可以重构成下面这样子 if (target.startsWith("#RANGE")) { processStartWithTag(); } else if (target.contains...进一步优化 在上面的优化之后,如何再用工厂模式来继续重构呢? 从上的代码看的出来,不同的条件下,执行的逻辑是不同的,那么可以把这种执行逻辑抽象出来,用多态的概念来定义不同的执行方式。...在经过这一轮重构之后,我们之前在一个类里面写的那堆代码已经抽离到多个不同的类里了, 现在在原来的类里的代码变成怎样了呢, TargetExecutor executor = ExecutorFactory.getExecutor...(target); executor.process(); 重构之后各个Executor和主类中的耦合已经降到很低了, 而且代码整洁度提高了很多,之前那个类的一段50+行的代码变成了2行,这就是重构的意义
传统的实现方式 我们看下边的伪代码,大致就是重构前下单逻辑的代码,由于来源比较少,简单的做if-else逻辑判断足以满足需求。...现在每种订单来源的处理逻辑都有几百行代码,看着已经比较臃肿,可我愣是迟迟没动手重构,一方面业务方总像催命鬼一样的让你赶工期,想快速实现需求,这样写是最快;另一方面是不敢动,面对古董级代码,还是想求个安稳...但这次来源一下子增加几十个,再用这种方式做已经无法维护了,想象一下那种臃肿的if-else代码,别说开发想想都头大!...return "处理促销订单"; } return null; } } 策略模式的实现方式 思来想去基于当前业务场景重构,还是用策略模式比较合适,它是oop中比较著名的设计模式之一...总结 凡事都有他的两面性,if-else多层嵌套和也都有其各自的优缺点: if-else的优点就是简单,想快速迭代功能,逻辑嵌套少且不会持续增加,if-else更好些,缺点也是显而易见,代码臃肿繁琐不便于维护
抛开剂量谈毒性都是耍流氓 在使用条件判断语句的地方,如果代码量小,需要判断的场景少的话, 那么没有比 if-else 更合适的语句,比如下面这样 .......if(object.getIndex() > 0) { //do something } else { //do other things } 那在什么情况下 if-else 才会变差呢?...如何重构掉这段代码 对于这种代码我们重构的目标可以有两个深度,看自己强迫症的严重程度决定 · 继续用 if-else,只达到剥离执行代码块 · 用工厂模式去耦合 对于这两种其实不是非此即彼的关系,而是优化深度不同...第一种相对比较简单,可以重构成下面这样子 ?...重构之后各个Executor和主类中的耦合已经降到很低了, 而且代码整洁度提高了很多,之前那个类的一段50+行的代码变成了2行,这就是重构的意义。
("开除"); } } } 可以看到,每增加一种情况都要增加一个if else判断,这样会造成这段代码非常长,可读性差、不易维护。...下面就用静态工厂+策略模式来重构这段代码(对于静态工厂模式和策略模式不知道的同学请自行百度哈 先说说思路:1、定义一个处罚的接口 ,包含一个执行处罚的方法 2、每一种情况的处罚都抽象成一个具体处罚类并继承处罚接口...implements IPunish { public void exePunish() { // Empty class } } } 重构后...static void main(String[] agrs){ String state ="late"; punish(state); } //重构后的处罚逻辑...IPunish punish = PunishFactory.getPunish(state); //执行处罚逻辑 punish.exePunish(); } } 重构后的处罚逻辑简单
Percona PT-kill重构版(PHP)概述 原生Percona版 PT-kill(Perl)工具只是单纯的KILL掉正在运行中的慢SQL,而不能作为一个监控工具使用,例如缺少邮件报警或者微信报警功能...,固需要将其重构。...重构版 PT-kill(PHP)从information_schema.PROCESSLIST表中捕获正在运行中的SELECT|ALTER等DML/DDL消耗资源过多的查询,过滤它们,然后杀死它们(可选择不杀...='dev' --kill --mail --weixin后台运行shell> nohup php pt-kill.php -u admin -p 123456 -h 10.10.159.31 -P 3306...4、--mail 为开启发送邮件报警,需先设置smtp_config.php,改成你自己的邮箱账号信息smtp_config.php ******************** 配置信息 *****
对于这两种情况重构的方法也不一样。 代码 if-else 代码太多有什么缺点? 缺点相当明显了:最大的问题是代码逻辑复杂,维护性差,极容易引发 bug。...如果使用 if-else,说明 if 分支和 else 分支的重视是同等的,但大多数情况并非如此,容易引起误解和理解困难。 是否有好的方法优化?如何重构? 方法肯定是有的。...重构 if-else 时,心中无时无刻把握一个原则: 尽可能地维持正常流程代码在最外层。 意思是说,可以写 if-else 语句时一定要尽量保持主干代码是正常流程,避免嵌套过深。...比对两个版本,会发现重构后的版本逻辑清晰,简洁易懂。 和重构前到底有什么区别呢? 最大的区别是减少 if-else 嵌套。...总结重构的要点:如果 if-else 嵌套没有关联性,直接提取到第一层,一定要避免逻辑嵌套太深。尽量减少临时变量改用 return 直接返回。
对于这两种情况重构的方法也不一样。 代码if-else代码太多有什么缺点? 缺点相当明显了: 最大的问题是代码逻辑复杂,维护性差,极容易引发bug。...如果使用if-else,说明if分支和else分支的重视是同等的,但大多数情况并非如此,容易引起误解和理解困难。 是否有好的方法优化?如何重构? 方法肯定是有的。...重构if-else时,心中无时无刻把握一个原则: 尽可能地维持正常流程代码在最外层。 意思是说,可以写if-else语句时一定要尽量保持主干代码是正常流程,避免嵌套过深。...比对两个版本,会发现重构后的版本逻辑清晰,简洁易懂。 和重构前到底有什么区别呢? 最大的区别是减少if-else嵌套。...总结重构的要点:如果if-else嵌套没有关联性,直接提取到第一层,一定要避免逻辑嵌套太深。尽量减少临时变量改用return直接返回。
switch if - else只适合在3层之内使用 当条件判断较多时,可以首先考虑使用switch interface 当判断条件还可能动态增加时,可以考虑将switch进一步优化,引入接口interface
在php7.2里面,如果模板里面使用了if else endif标签的话,类似: have_posts() ) : ?...else: ?> XXXXXXx 这种模板标签,会报如下的错误提示: syntax error, unexpected end of file, expecting elseif (T_ELSEIF) or else (T_ELSE...endif (T_ENDIF) 仔细检查没看到语法提示,这个时候是因为php.ini里面的short_open_tag标签没开启,默认的示关闭的, 在php.ini里面设置short_open_tag...= On; 重启php即可。
python 中 if 的用法(if else, if not, elif) if语句实际上是:if True: …执行后面的语句 python 中的 if 有下面几种常见用法: if … else...… if …elif…else… if not … if … not … 1.if … else … 实际上,还可以用用下面这种方式,使代码更精简: 赋值也是可以的: 2....if … elif … else… elif 是多条件判断语句,比如: 当然,当条件很多时,可以有多个elif,比如上面这个简单的例子可以再增加几个条件 3.if not … i在讲 if...弄清楚not之后,加上 if 就很简单了,如果if not 后面的语句是False,则执行冒号后面的语句,否则执行else(如果有else的话)。
package main import "fmt" func main() { var a =10; if a>10 { //大括号前不能回车 fmt.Println("dayu10") }else...if a<10{ fmt.Println("xiaoyu10"); }else { fmt.Println("10") } } //没什么好过多介绍就这样......func main() { a := 2 switch a { case 1: //相当于if a==1 fmt.Println("等于1") default: //相当于else...import "fmt" func main() { a := 1 switch { case a==1: fmt.Println("等于1") default: //相当于else...fmt.Println("等于1") fallthrough //只要代码读到fallthrough与他紧挨着的无论是否满足条件他都会执行里面的内容 default: //相当于else
因为else哪里没用判断语句啊,兄dei php $gg=666; if($gg<999){ # code......echo "抱歉不是这个"; } else { echo "是这个没差了"; } ?> 三元运算符: php $gg=666; $a=$gg 自己去运行,提高动手能力啊 if else if else: 核心是:如果不是我,就是它,不是就是另一个它,如果都没有抱歉,执行最后的计划else把 <?...echo "1"; } else if($gg<=665)//大于等于0小于666的 { echo "2"; } else//代表的是等于666包括以上的 { echo "666"; } ?...> switch: 这里的default像else一样哈 case像if else if一样的哈 只不过是换一个形式而已 直接上代码把 <?
(true block) : (else block)来设置一行if / else语句的var variable = (condition) ?...(true block) : (else block) var variable = (condition) ?...(true block) : (else block) ,但我想知道是否有办法在其中放入else if语句。 任何建议,将不胜感激,谢谢大家! 当然,你可以做嵌套的三元操作符,但它们很难阅读。...(true block2) : (else block2)) TL;博士 是的,你可以...如果一个然后一个,否则如果B然后如果C然后C(B),否则B,否则空 a ? a : (b ?...:用作内联if-else是正确的关联 。 总之这意味着最右边的? 获得第一喂,它需要只有一个操作数最接近的左侧两个 ,有: ,在右边。 实际上,请考虑以下声明(与上述相同): a ?
for fruit in fruits: print(fruit.capitalize()) # Output: Apple # Banana # Mango else...语句 For循环也有一个我们大多数人都不熟悉的else子句。...else子句在循环正常完成时执行。 这意味着循环没有遇到任何break。 常见的构造是运行一个循环并搜索一个项目。 如果找到该项目,我们使用break来断开循环。...另一个是使用else子句。...process(item) break else: # Didn't find anything..
,互不干扰的,你执行你的 if - else ,我执行我的 if - else ; 在Java中 if-else 与 if-else if-else之间不同执行顺序: 一、首先要了解 if - else...与 if - else if - else 之间的本质是不一样的: 1、if - else 是 单条件双分支 语句; if - else if - else 是 多条件分支 语句 ; if -...if-else语句 } 那么 if-else 与 if-else if-else之间不同执行顺序是: 对于 if - else 语句,系统程序只会进行一次表达式的判断,当表达式的值为...{ } 中的若干语句,并结束当前整个语句; 需要注意的是:有多个 else if 语句的情况下,如 if - else if - else if - else if - else : 要是 if 中表达式为...、if-else if-else语句 与 switch 开关语句 之间的异同点: 1、if、if-else、if- else if- else 语句 之间的共同点是程序根据 一个条件执行一个分支操作,
count = 0 2 while count <= 5 : 3 count += 1 4 if count == 3:pass 5 print("Loop",count) 6 7 else...= 0 2 while count <= 5 : 3 count += 1 4 if count == 3:break 5 print("Loop",count) 6 7 else...("-----out of while loop ------") Loop 1 Loop 2 -----out of while loop ------ 结论:while循环正常执行完不会执行else...里边的代码,如果while循环被break中断则会执行else里边的代码
通常能不用分支语句,我尽量不会使用,因为我觉得if/else很丑,每每看到if/else代码,总会以挑剔的眼光看待它,想想能不能重构的更好。...针对这种恶心的if/else分支,我们当然首先想到的去重构它–在不改变代码外部功能特征的前提下对代码内部逻辑进行调整和优化,但,如何做呢?...前段时间在项目中正好遇到一个恶心的if/else例子,想在这篇博客里和大家分享一下去除if/else重构的历程。 ?...就系统整体架构而言,重构可能需要很大的改动,可能在架构流程上需要评审;就功能内代码层次而言,这种重构在我们编码过程中随时可以进行,类似于if/else,swicth/case这种代码的重构也属于这种类型...重构的最终结果不一定会让代码变少,相反还有可能增加程序的复杂度和抽象性,就本例中的if/else而言,确实如此。
领取专属 10元无门槛券
手把手带您无忧上云