为啥你写的代码老有大串的if/else?
摘要:控制语句,到底何错之有呢?
本文分享自华为云社区《业务代码如何才能不再写出大串的if/else?》,作者: JavaEdge 。
控制结构?没错!你最爱的 if、for都是一类坏味道,没想到吧?自己竟然每天都沉浸在写坏味道的体验中。
控制语句,到底何错之有呢?
嵌套代码
CR 如下分发我刚写完的一篇博客的案例:
逻辑很简单,但有多层缩进,for 循环一层,里面有俩 if ,又多加两层。若逻辑再复杂点,缩进岂不是像啤酒肚一般越来越大?
为啥代码会写成这鬼样子呢?
因为你在写流水账,如机器人般地按需求一步步翻译成代码。
代码逻辑肯定没错,但功能实现后,未重新整理代码。
现在就得消除缩进。
从for循环入手,通常for循环处理集合,而循环里处理的是该集合中的元素。所以,可将循环中的内容提取成方法,只处理一个元素:
这就是一次拆分,分解出来事务 issueArticle 每次只处理一个元素。这就优化了缩进问题:
- issueArticles 只有一层缩进,这才是正常方法应有的样子。
- 但 issueArticle 还残留多层缩进,待继续优化。
if 和 else
issueArticle 里,造成缩进的原因是 if 语句。if 缩进很多时候都是在检查某先决条件,条件通过时,才能执行后续代码。
这样的代码可使用卫语句(guard clause),即设置单独检查条件,不满足该检查条件时,方法立刻返回。
以卫语句取代嵌套的条件表达式(Replace Nested Conditional with Guard Clauses)。
重构后的 issueArticle 函数:
如今这就只剩一层缩进,代码复杂度大大降低,可读性和可维护性也大大增强。
禁用else
大多数人印象中,if 和 else 几乎比翼齐飞。
else 可以不写吗?
可以!
根据文章信息进行收费:
不用 else,简单方式就是让每个逻辑提前返回,类似卫语句:
业务简单的代码,这重构还很轻松,但对复杂代码,就得上多态了。
嵌套、else 语句,都是坏味道,本质上都在追求简单,因为一段代码的分支过多,其复杂度就会大幅度增加。
衡量代码复杂度常用的标准,圈复杂度(Cyclomatic complexity,CC),CC越高,代码越复杂,理解和维护的成本越高。
在CC判定中,循环和选择语句占主要地位。CC可使用工具检查,如Checkstyle,可限制最大的圈复杂度,当圈复杂度大于设定阈值,就报错。
重复 Switch
实际支付的价格会根据用户在系统中的用户级别有所差异,级别越高,折扣越高。
两个函数里出现了类似的代码,其中最类似部分就是 switch,都据用户级别判断。
这并非仅有的根据用户级别进行判断的代码,各种需区分用户级别场景都有类似代码,而这也是一种典型的坏味道:重复switch(Repeated Switch),通常都是因为缺少一个模型。
解决方案:以多态取代条件表达式(Relace Conditional with Polymorphism)。
引入 UserLevel 模型,消除 switch:
前面代码即可去掉 switch:
switch 其实就是一堆“ if…else” 的简化写法,二者等价,所以,这个重构手法,以多态取代的是条件表达式,而不仅是取代 switch。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
全链路数据血缘在满帮的实践
摘要:全链路数据血缘,指在数据的全生命周期内,数据与数据之间会形成各式各样的关系,贯穿整个数据链路中。 本文分享自华为云社区《全链路数据血缘在满帮的实践》,作者: 你好_TT。 什么是全链路数据血缘 根据维基百科定义,数据血缘(Data Lineage)又叫做数据起源(Data Provenance)或者数据家谱(Data Pedigree)。其通常被定义为一种生命周期,主要包含数据的来源以及数据随时间移动的位置。 数据血缘是数据资产的重要组成部分,用于分析表和字段从数据源到当前表的血缘路径,以及血缘字段之间存在的关系是否满足,并关注数据一致性以及表设计的合理。它描述了数据从收集,生产到服务的全链路的变化和存在形式。 全链路数据血缘,指在数据的全生命周期内,数据与数据之间会形成各式各样的关系,贯穿整个数据链路中,如图1所示。 图1 全链路数据血缘 血缘构建方案调研 血缘解析 当前,数据血缘大多是对SQL语句进行解析,以发现上下游调用栈等信息。主流方案可分为两种: 运行时解析,即在任务运行时通过hook接口或者listener接口对SQL生成的逻辑技术树(AST)进行解析。 先采集后解析...
- 下一篇
服务网格(Service Mesh)在中国工商银行的探索与实践
导读 ServiceMesh是下一代的微服务架构基础。蚂蚁集团从 2018 年初开始技术探索并进行了落地试点。目前, Service Mesh 覆盖了蚂蚁集团数千个应用,实现了核心链路全覆盖。蚂蚁集团通过 Service Mesh 的大规模落地向云原生走出了坚实的一步,真切看到了基础设施下沉后为业务快速增长提供了支撑,以及对基础设施团队在研发和运维效率的提升、成本的降低上带来极大收益。现在,Service Mesh技术解决方案也正在开放给社会。 下文为工商银行在应用蚂蚁Service Mesh方面的实践案例。 微服务架构是当今互联网和金融机构渐趋主流的系统架构模式,其核心是集成服务通信、服务治理功能的服务框架,微服务框架在持续演进同时,服务网格(Service Mesh)作为一种新型的微服务架构,因架构灵活、普适性强,被认为具有较好发展前景。 中国工商银行(后简称工行)主动探索服务网格领域,从2019年开始服务网格技术预研工作,通过对服务网格技术深入研究和实践后,于2021年建设了服务网格平台。服务网格与现有微服务架构融合发展,助力工行应用架构向分布式、服务化转型,承载未来开放平台核心...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2更换Tomcat为Jetty,小型站点的福音