【重构.改善既有代码的设计】9、简化条件表达式

简化条件表达式

Decompose Conditional(分解条件式)

你有一个复杂的条件(if-then-else)语句。 从if、then、else 三个段落中分别提炼出独立函数。

分解为多个独立函数,根据每个小块代码的用 途,为分解而得的新函数命名,并将原函数中对应的代码替换成「对新建函数的调用」,从而更清楚地表达自己的意图。

对于条件逻辑,[将每个分支条件分解,形成新函数」还可以给你带来更多好处:可以突出条件逻辑,更清楚地表明每个分支的作用,并且突出每个分支的原因。

Consolidate Conditional Expression(合并条件式)

你有一系列条件测试,都得到相同结果。

将这些测试合并为一个条件式,并将这个条件式提炼成为一个独立函数。

比如:入参检测。

Consolidate Duplicate Conditional Fragments(合并重复的条件片段)

在条件式的每个分支上有着相同的一段代码。

将这段重复代码搬移到条件式之外。

Remove Control Flag(移除控制标记)

在一系列布尔表达式(boolean expressions)中,某个变量带有「控制标记」(control flag)的作用。

以break 语句或return 的语句取代控制标记。

当然,如果这些语句并不能取到该有的效果,还是要控制标记。

Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件式)

什么叫卫语句? if(false)return; 什么叫不是卫语句? if(ture){xxxxx};

目的:逻辑清晰。

Replace Conditional with Polymorphism(以多态取代条件式)

取代switch大法。

Introduce Null Object(引入Null 对象)

将null value (无效值)替换为null object(无效物)。

就是尽量不用null,而用一个内容为null的可以访问的Object。

特别有用的地方:list,如果是null,则要判断,如果是空list,则不需要判断,但遍历仍然不会做事情。

但对一个普通类,如何获取一个Null对象?创建一个Null前缀的子类,这个类的方法要注意适配下。当然,这就变的复杂了起来,所以要衡量是否需要这么做。

Introduce Assertion(引入断言)

注意断言不要滥用,

它只应该用于一定必须为真的地方,而不是应该为真的地方。

原作者的总结

条件逻辑(conditional logic)有可能十分复杂,因此本章提供一些重构手法,专门用来简化它们。

其中一项核心重构就是 Decompose Conditional ,可将一个复杂的条件逻辑分成若干小块。这项重构很重要,因为它使得「转辙逻辑」(switching logic )和「操作细节」(details)分离。

本章的其余重构手法可用以处理另一些重要问题:

如果你发现代码中的多处测试有相同结果,应该实施Consolidate Conditional Expression;如果条件代码中有任何重复,可以运用Consolidate Duplicate Conditional Fragments 将重复成分去掉。

如果程序开发者坚持「单一出口(one exit point )」原则,那么为让条件式也遵循这 一原则,他往往会在其中加入控制标记(control flags )。我并不特别在意「一个函数一个出口」原则,所以我使用 Replace Nested Conditional with Guard Clauses 标示出那些特殊情况,并使用Remove Control Flag 去除那些讨厌的控制标记。

较之于过程化(procedural )程序而言,面向对象(object oriented)程序的条件式通常比较少,这是因为很多条件行为都被多态机制(polymorphism)处理掉了。多态之所以更好,是因为调用者无需了解条件行为的细节,因此条件的扩展更为容易。所以面向对象程序中很少出现switch 语句;一旦出现,就应该考虑运用Replace Conditional with Polymorphism 将它替换为多态。

多态还有一种十分有用但鲜为人知的用途:通过 Introduce Null Object 去除对于null value 的检验。

我的总结

1、可以用多态替代条件。
2、复杂条件要拆分
3、重复的要合并
4、空对象的妙用,还能用于多态。

原文地址:https://www.cnblogs.com/aoyihuashao/p/10384715.html

时间: 2024-10-02 04:48:17

【重构.改善既有代码的设计】9、简化条件表达式的相关文章

《重构--改善既有代码的设计》总结or读后感:重构是程序员的本能

此文写得有点晚,记得去年7月读完的这本书,只是那时没有写文章的意识,也无所谓总结了,现在稍微聊一下吧. 想起写这篇感想,还是前几天看了这么一篇文章 研究发现重构软件并不会改善代码质量 先从一个大家都有的经历说起吧. 刚开始学编程时,比如,要统计数字出现的次数,我们会这么定义变量 int i=0;//统计次数 老师看了说,代码要有可读性,见名知意; 于是,我们把它改成 int count=0; 后来才知道,原来这么一手这就是重构的第一式,重命名 (eclipse快捷键 alt+shift+R,最近

《重构——改善既有代码的设计》读书笔记

重构--改善既有代码的设计 1 重构概述 1.1 重构的概念(What) Refactoring 名词:对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低修改成本. 动词:使用一系列重构方法,在不改变软件可观察行为的前提下,调整其结构. 1.2 为什么要重构(Why) 改进软件设计 提高代码质量和可读性,使软件系统更易理解和维护 帮助尽早的发现缺陷 提高编程速度 1.3 何时重构(When) 何时重构: 1)随时随地进行. 2)三次法则:第一次做某件事只管去做:

【转】PHP 杂谈《重构-改善既有代码的设计》之一 重新组织你的函数

原文地址: PHP 杂谈<重构-改善既有代码的设计>之一 重新组织你的函数 思维导图 点击下图,可以看大图. 介绍 我把我比较喜欢的和比较关注的地方写下来和大家分享.上次我写了篇<php 跟老大的对话>.还是有很多疑问,这书帮了我不少的忙. 如果你比较繁忙,或者懒得看文字,建议你直接看截图,也会有很大的收获的.你可以通过比较截图中的代码就能知道孰优孰劣了. 代码部分我为什么用图呢?因为我经常用手机看代码,博客园的代码在手机里乱七八糟的,还是看图比较舒服. 专业术语 我们毕竟是用英文

重构改善既有代码的设计思维导图

最近闲来无事就把之前看的书,做了一张张的思维导图,来分享给大家 重构改善既有代码的设计思维导图: --------------- 不知道是博客园的问题,还是我的浏览器的问题,图片没法上传,如有人想要想看 可以给我发邮件: [email protected]  只为共同学习.也可以留言!!!

好书推荐之:重构-改善既有代码的设计

下载地址 高清 1.3M 重构-改善既有代码的设计 版权声明:本文为博主原创文章,未经博主允许不得转载.

《重构&mdash;&mdash;改善既有代码的设计》【PDF】下载

<重构--改善既有代码的设计>[PDF]下载链接: https://u253469.ctfile.com/fs/253469-231196358 编辑推荐 重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码.多年前,正是<重构:改善既有代码的设计>原版的出版,使重构终于从编程高手们的小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分.<重构:改善既有代码的设计>也因此成为与<设计模式>齐名的经典著作,被译为中.德.俄.日等众多语言,

实践提高《重构改善既有代码的设计第2版》PDF中文+PDF英文+对比分析

重构是编程的基础,是在不改变外部行为的前提下,有条不紊地改善代码.编程爱好者都知道,Martin Fowler 的<重构:改善既有代码的设计>已经成为全球有经验的程序员手中的利器,既可用来改善既有代码的设计.提升软件的可维护性,又可用于使既有代码更易理解.焕发出新的活力. <重构改善既有代码的设计(第2版)>在第1 版的基础上做了全面修订,反映了编程领域业已发生的许多变化.第2 版中介绍的重构列表更加内聚,并用JavaScript 语言重写了代码范例.此外,第2 版中还新增了与函数

《重构-改善既有代码的设计》读书笔记

重构,第一个案例 1.1 起点 如果发现现有的代码结构使你无法很方便地添加新特性,那就先重构,使特性的添加比较容易进行后,再添加特性; 1.2 重构的第一步 为即将修改的代码建立可靠的测试环境 – 是人就会犯错,所以需要可靠的测试; 测试结果能够自我检验 – 成功"OK",失败列出失败清单并打印行号 (自动化对比测试结果是提高效率的前提); 1.3 分解并重组"巨型"函数 切分提炼长函数(Extract Method),并移至更合适的类(Move Method) –

《重构—改善既有代码的设计》笔记

为什么要重构 改进软件设计,消除重复代码 保持代码易读.易修改 提高编程速度(良好设计师维持软件开发速度的根本) 发现BUG 什么时候重构 事不过三,三则重构(三次法则) 添加功能时一并重构 修改错误时一并重构 复审代码时一并重构 问题代码 重复的代码 过长函数 过大类 过长参数列表 发散式变化 霰弹式修改 依恋情节 数据泥团 基本型别偏执 switch惊悚现身 冗赘类 夸夸其谈未来性 令人迷惑的暂时值域 过度耦合的消息链 中间转手人 狎昵关系 异曲同工的类 不完美的程序库类 纯稚的数据类 被拒

重构-----改善既有代码的设计

1重构原则 1.1 定义: 1).调整软件内部结构,目的是在不改变软件软件可查行为前提下,提高其可理解性,降低其修改成本. 2).使用一系列重构准则,在不改变软件可查行为前提下,调整其结构 1.2 何时重构 1).三次法则 2).添加功能时 3).修补错误时 4).复审代码时 1.3 何时不该重构 1).代码太乱,重构效率低于重写效率时 2).项目接近期限时停止重构 2.代码的坏味道 2.1 Duplicated Code 2.2 Long Method 2.3 Large Class 2.4