不懂就问，if/else构成的屎山快堆成珠穆朗玛峰了咋办？

逍遥设计自动化 · 发表于 2024-1-25 08:30:00

点击上方“C语言与CPP编程”，选择“关注/置顶/星标公众号”
干货福利，第一时间送达！

xcdky3v3l3a6409659942.png

最近有小伙伴说没有收到当天的文章推送，这是因为微信改了推送机制，有一部分小伙伴刷不到当天的文章，一些比较实用的知识和信息，错过了就是错过了，建议大家加个星标??，就能第一时间收到推送。

cn4kvq2mwu26409660042.png

前期迭代懒得优化，来一个需求，加一个if，久而久之，就堆成了一座山。

c2w4o0zjstc6409660142.png

当代码已经复杂到难以维护的程度之后，只能狠下心重构优化。
那，有什么方案可以优雅的优化掉这些多余的if/else?观点一：消灭if/else1 提前 return这是判断条件取反的做法，代码在逻辑表达上会更清晰，看下面代码：

if (condition) {// do something}else{return xxx;}其实，每次看到上面这种代码，我都心里抓痒。完全可以先判断!condition，干掉 else。

if (!condition) {return xxx;
} // do something2 策略模式有这么一种场景，根据不同的参数走不同的逻辑，其实这种场景很常见。最一般的实现：

if (strategy.equals("fast")) {// 快速执行} else if (strategy.equals("normal")) {// 正常执行} else if (strategy.equals("smooth")) {// 平滑执行} else if (strategy.equals("slow")) {// 慢慢执行}看上面代码，有4种策略，有两种优化方案。2.1 多态

interface Strategy {void run() throws Exception;}
class FastStrategy implements Strategy {@Overridevoid run() throws Exception    {// 快速执行逻辑 }}
class NormalStrategy implements Strategy {@Overridevoid run() throws Exception    {// 正常执行逻辑 }}
class SmoothStrategy implements Strategy {@Overridevoid run() throws Exception    {// 平滑执行逻辑 }}
class SlowStrategy implements Strategy {@Overridevoid run() throws Exception    {// 慢速执行逻辑 }}具体策略对象存放在一个Map中，优化后的实现：

Strategy strategy = map.get(param);strategy.run();上面这种优化方案有一个弊端。为了能够快速拿到对应的策略实现，需要map对象来保存策略。当添加一个新策略的时候，还需要手动添加到map中，容易被忽略。2.2 枚举发现很多同学不知道在枚举中可以定义方法。这里定义一个表示状态的枚举，另外可以实现一个run方法。

public enum Status{ NEW(0) {@Overridevoid run() {//do something } }, RUNNABLE(1) {@Overridevoid run() {//do something } };
public int statusCode;
abstract void run();
Status(int statusCode) {this.statusCode = statusCode; }}重新定义策略枚举：

public enum Strategy { FAST {@Overridevoid run() {//do something       } }, NORMAL {@Overridevoid run() {//do something       } },
SMOOTH {@Overridevoid run() {//do something       } },
SLOW {@Overridevoid run() {//do something       } };abstract void run();}通过枚举优化之后的代码如下:

Strategy strategy = Strategy.valueOf(param);strategy.run();3 学会使用 Optional
Optional主要用于非空判断，由于是jdk8新特性，所以使用的不是特别多。但是用起来真的爽，使用之前：

if (user == null) {//do action 1}else{//do action2}如果登录用户为空，执行action1，否则执行action 2。使用Optional优化之后，让非空校验更加优雅，间接的减少if操作：

Optional[U] userOptional = Optional.ofNullable(user);userOptional.map(action1).orElse(action2);4 数组小技巧来自google解释，这是一种编程模式，叫做表驱动法。本质是从表里查询信息来代替逻辑语句。比如有这么一个场景：通过月份来获取当月的天数，仅作为案例演示，数据并不严谨。一般的实现：

int getDays(int month){if (month == 1) return 31;if (month == 2) return 29;if (month == 3) return 31;if (month == 4) return 30;if (month == 5) return 31;if (month == 6) return 30;if (month == 7) return 31;if (month == 8) return 31;if (month == 9) return 30;if (month == 10) return 31;if (month == 11) return 30;if (month == 12) return 31;}优化后的代码:

int monthDays[12] = {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};int getDays(int month){return monthDays[--month];}if else 作为每种编程语言都不可或缺的条件语句，在编程时会大量的用到。
一般建议嵌套不要超过三层。如果一段代码存在过多的if else嵌套，代码的可读性就会急速下降。后期维护难度也大大提高。观点二：让语义清晰不要去过度关注 if/else 的层数，而要关注接口语义是否足够清晰；单纯减少if/else的层数，然后拆出一堆do_logic1, do_logic2…这样的接口是毫无帮助的。任何一个接口的执行过程都可以表示为：输入 + 内部状态 -> 输出这样的形式，我们分以下几种情况来讨论：输入、内部状态、输出都很简单，但中间逻辑复杂。比如说一个精心优化过的数值计算程序，可能需要根据输入在不同的取值范围采取不同的策略，还有很多逻辑用来处理会引发问题（比如除0）的边界值，这种情况下 if/else 数量多是难以避免的。根据步骤拆分出一些内部方法有一定帮助，但也不能完全解决问题。这种情况下最好的做法是写一篇详细的文档，从最原始的数学模型开始，然后表明什么情况下采取什么样的计算策略，策略如何推导，知道得到代码中使用的具体形式，然后给整个方法加上注释附上文档地址，并且在每个分支的地方加上注释指明对应到文档中哪个公式。这种情况下虽然方法很复杂，但是语义是清晰的，如果不修改实现的话理解语义就行了，如果要修改实现那么需要参考对照文档中的公式。输入过于复杂，比如输入带有一堆不同的参数，或者有各种奇怪的flag，每个flag有不同作用。这种情况下首先需要提高接口的抽象层次：如果接口有多个不同作用，需要拆分成不同接口；如果接口内部根据不同参数进不同分支，需要将这些参数和对应分支包在Adapter里，使用参数的地方改写成Adapter的接口，根据传入的Adapter类型不同进入不同的实现；如果接口内部有复杂的参数转换关系，需要改写成查找表。这种情况下的主要问题是接口本身抽象的有问题，有更清晰的抽象之后，实现也自然没有那么多if/else了。输出过于复杂，为了省事一个过程计算出了太多东西，又为了性能加了一堆flag控制是否计算之类。这种情况下需要果断将方法拆分成多个不同方法，每个方法只返回自己需要的内容。如果不同计算之间有共用的内部结果呢？如果这个内部结果计算并不形成瓶颈，只要提取出内部方法然后在不同过程中分别调用即可；如果希望避免重复计算，可以增加一个额外的 cache 对象作为参数，cache内容对用户不透明，用户只保证相同输入使用同一个cache对象即可，在计算中将中间结果保存到cache中，下次计算前先检查有没有已经得到的结果，就可以避免重复计算了。内部状态过于复杂。首先检查状态设置的是否合理，是不是有一些本来应该作为输入参数的东西被放到了内部状态中，比如用来隐式地在两个不同方法调用之间传递参数？其次，这些状态分别控制哪些方面，是否可以分组然后实现到不同的 StateManager里面？第三，画出状态转移图，尝试将内部状态分成单层分支，然后分别实现到on_xxx_stat e这样的方法里面，然后通过单层的 switch 或者查找表来调用。其实通常需要优化的都是整体接口抽象，而不是单个接口的实现，单个接口实现不清晰通常是因为接口实现和需求不同构造成的。原文：https://www.zhihu.com/question/344856665/answer/816270460——EOF——你好，我是飞宇，本硕均于某中流985 CS就读，先后于百度搜索、字节跳动电商以及携程等部门担任Linux C/C++后端研发工程师。
最近跟朋友一起开发了一个新的网站：编程资源网，已经收录了不少资源（附赠下载地址），如果屏幕前的靓仔/女想要学习编程找不到合适资源的话，不妨来我们的网站看看，欢迎扫码下方二维码白嫖~

1rkrv5bvcsp6409660243.gif

同时，我也是知乎博主@韩飞宇，日常分享C/C++、计算机学习经验、工作体会，欢迎点击此处查看我以前的学习笔记&经验&分享的资源。
我组建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起进群交流。

lb0tlsfemrv6409660343.png

欢迎你添加我的微信，我拉你进技术交流群。此外，我也会经常在微信上分享一些计算机学习经验以及工作体验，还有一些内推机会。

c2okcalcxuu6409660443.png

加个微信，打开另一扇窗

1ey4dvoelix6409660543.gif