CTO怒了:再写if-else,逮着罚款1000!

来自公众号:51CTO技术栈

作者:Nicklas Millard,在丹麦的四大咨询公司之一中担任高级技术顾问,主要担任客户项目的首席开发人员和解决方案架构师。

编辑:陶家龙

出处:https://medium.com/swlh/5-ways-to-replace-if-else-statements-857c0ff19357

本文并不肯定或者否定哪一种写法,仅仅为大家提供一些其他的编码思路或者一些值得借鉴的点子。

设计更好的软件,替换 If-Else 的 5 种方法,从入门到高级示例

If-Else 通常是一个糟糕的选择,它导致设计复杂,代码可读性差,并且可能导致重构困难。

但是,If-Else 已成为事实上的代码分支解决方案,这确实是有道理的。这是向所有有抱负的开发人员讲授的第一件事。

不幸的是,许多开发人员从来没有前进到更合适的分支策略。有些人的口头禅是:If-Else 是一把锤子,一切都是钉子。

我将向大家展示一些技巧和模式,这些技巧和模式将终结这种可怕的做法。每个示例的难度都会增加。

完全不必要的 Else 块

这也许是那些初级开发人员最负罪的之一。下面的示例很好地说明了当你被认为 If-Else 很棒时会发生什么:

Simple if-else

只需删除 else` 块即可简化此过程,如下图:

Removed else

看起来更专业吧?你会发现,实际上根本不需要其他块。像在这种情况下一样,你想要在满足特定条件的情况下执行某些操作并立即返回。

价值分配

如果你要根据提供的某些输入为变量分配新值,请停止 If-Else 废话,一种更具可读性的方法。

Value assignment with if-else

尽管很简单,但它却很糟糕。首先,If-Else 很容易在这里被开关取代。但是,我们可以通过完全删除 else 来进一步简化此代码。

If statements with fast return

如果不使用 else,则我们将剩下干净的可读代码。请注意,我也将样式更改为快速返回而不是单返回语句。如果已经找到正确的值,继续测试一个值根本没有意义。

前提条件检查

通常,我发现,如果方法提供了无效的值,则继续执行是没有意义的。假设我们从以前就有了 DefineGender 方法,要求提供的输入值必须始终为 0 或 1。

Method without value checks

在没有价值验证的情况下执行该方法没有任何意义。因此,在允许方法继续执行之前,我们需要检查一些先决条件。

应用保护子句防御性编码技术,你将检查方法的输入值,然后继续执行方法。

Check preconditions with guard clauses

至此,我们确保仅在值落在预期范围内时才执行主逻辑。现在,IF 也已被三元代替,因为不再需要在结尾处默认返回"未知"。

将 If-Else 转换为字典,完全避免 If-Else

假设您需要执行一些操作,这些操作将根据某些条件进行选择,我们知道以后必须添加更多操作。

也许有人倾向于使用久经考验的 If-Else。如果添加新操作,则只需简单地添加其他内容即可。很简单 但是,就维护而言,这种方法不是一个好的设计。

知道我们以后需要添加新的操作后,我们可以将 If-Else 重构为字典。

可读性已大大提高,并且可以更轻松地推断出该代码。注意,仅出于说明目的将字典放置在方法内部。您可能希望从其他地方提供它。

扩展应用程序,完全避免使用 If-Else

这是一个稍微高级的示例。通过用对象替换它们,知道何时甚至完全消除 If。

通常,您会发现自己不得不扩展应用程序的某些部分。作为初级开发人员,您可能会倾向于通过添加额外的 If-Else(即 else-if)语句来做到这一点。

举这个说明性的例子。在这里,我们需要将 Order 实例显示为字符串。首先,我们只有两种字符串表示形式:JSON 和纯文本。

在此阶段使用 If-Else 并不是什么大问题,如果我们可以轻松替换其他,只要如前所述即可。

知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。

上面的代码不仅违反了"打开/关闭"原则,而且阅读得不好,还会引起可维护性方面的麻烦。

正确的方法是遵循 SOLID 原则的方法,我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。

重构这个混乱的过程的过程如下:

  • 使用公共接口将每个分支提取到单独的策略类中。

  • 动态查找实现通用接口的所有类。

  • 根据输入决定执行哪种策略。

替换上面示例的代码如下所示。是的,这是更多代码的方式。它要求您了解类型发现的工作原理。但是动态扩展应用程序是一个高级主题。

我只显示将替换 If-Else 示例的确切部分。如果要查看所有涉及的对象,请查看此要点。

让我们快速浏览一下代码。方法签名保持不变,因为调用者不需要了解我们的重构。

首先,获取实现通用接口 IOrderOutputStrategy 的程序集中的所有类型。然后,我们建立一个字典,格式化程序的 displayName 的名称为 key,类型为 value。

然后从字典中选择格式化程序类型,然后尝试实例化策略对象。最后,调用策略对象的 ConvertOrderToString。

- EOF -

想要加入中生代架构群的小伙伴,请添加群合伙人大白的微信

申请备注(姓名+公司+技术方向)才能通过哦!

阿里技术精彩文章推荐

往期推荐

深度:揭秘阿里巴巴的客群画像

多隆:从工程师到阿里巴巴合伙人

阿里技术专家楚衡:架构制图的工具与方法论

蚂蚁集团技术专家山丘:性能优化常见压测模型及优缺点

阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?

阿里专家马飞翔:一文读懂架构整洁之道

阿里专家常昊:新人如何上手项目管理?

蚂蚁集团沈凋墨:Kubernetes-微内核的分布式操作系统

阿里合伙人范禹:常挂在阿里技术人嘴边的四句土话

阿里技术专家都铎:一文搞懂技术债

支付宝研究员兼OceanBase总架构师杨传辉:我在数据库梦之队的十年成长路

阿里技术专家麒烨:修炼测试基本功

阿里计算平台掌门人贾扬清:我对人工智能方向的一点浅见

蚂蚁资深算法专家周俊:从原理到落地,支付宝如何打造保护隐私的共享智能?

阿里高级技术专家箫逸:如何画好一张架构图?

阿里高级技术专家张建飞:应用架构分离业务逻辑和技术细节之道

蚂蚁科技 Service Mesh 落地实践与挑战 | GIAC 实录

阿里6年,我的技术蜕变之路!

蚂蚁集团涵畅:再启程,Service Mesh 前路虽长,尤可期许

阿里P9专家右军:大话软件质量稳定性

阿里合伙人程立:阿里15年,我撕掉了身上两个标签

阿里高工流生 | 云原生时代的 DevOps 之道

阿里高级技术专家邱小侠:微服务架构的理论基础 - 康威定律

阿里P9专家右军:以终为始的架构设计

阿里P8架构师:淘宝技术架构从1.0到4.0的架构变迁!12页PPT详解

阿里技术:如何画出一张合格的技术架构图?

蚂蚁资深技术专家王旭:开源项目是如何让这个世界更安全的?

阿里资深技术专家崮德:8 个影响我职业生涯的重要技能

儒枭:我看技术人的成长路径

阿里高级技术专家宋意:平凡人在阿里十年的成长之旅

阿里技术专家甘盘:浅谈双十一背后的支付宝LDC架构和其CAP分析

阿里技术专家光锥:亿级长连网关的云原生演进之路

阿里云原生张羽辰:服务发现技术选型那点事儿

蚂蚁研究员玉伯:做一个简单自由有爱的技术人

阿里高级技术专家至简: Service Mesh 在超大规模场景下的落地挑战

阿里巴巴山猎:手把手教你玩转全链路监控

阿里涉江:你真的会学习吗?从结构化思维说起

蚂蚁金服资深技术专家经国:云原生时代微服务的高可用架构设计

深入分布式缓存之EVCache探秘开局篇

   END     
#架构师必备#

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值