PHP 杂谈《重构-改善既有代码的设计》之四 简化条件表达式_php技巧

思维导图
点击下图,查看大图。

 介绍

 

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

 

全文简述(你可直接跳过下面的内容)

  核心重构:Decompose Conditional——分离”转辙逻辑“(switching logic)和”操作细节“(details)分离。

  多处测试有相同结果:Consolidate Conditional Expresssion

  条件代码中去掉重复成分:Consolidate Duplicate

  标识特殊情况:Replace Nested Conditional with Guard Clauses

  去除讨厌的控制标记:Remove Control Flag

 

 

 专业术语

 

decompose:分解,分离

consolidate:合并

eligible:合适的,合格的

fragment:碎片,片段

nest:嵌套

guard:保卫

clause:从句

polymorphism:多态

assertion:断言

unchecked exception:不可控异常

 

 Decompose Conditional

 

状况:你有一个复杂的条件(if-else if-else)语句,那么从if、else if、else三个段落中分别提炼出函数。

 

 

 

 Consolidate Conditional Expression

 

状况:你有一些条件测试,都得到相同的结果,那么将这些测试合并为一个条件式,并将这个条件提炼称为一个独立的函数。

动机: 1、合并后的条件代码会告诉你“实际上只有一次条件检查,只不过有数个并列条件需要检查而已“,——使检查的用意更清晰。

     2、为Extract Method做好准备。——将检查条件提炼成一个独立函数,对于理清代码意义非常有用。它把描述“做什么”的语句换成了“为什么这样做”。

 

条件语句的“合并理由”也同时指出了“不要合并”的理由:如果你认为你的这些检查的确彼此独立,的确不应该被视为同一次检查,那么就不要使用本项重构。因为在这种情况下,你的代码已经清楚表达出自己的意义。

 

 

 Consolidate Duplicate Conditional Fragments

 

状况:在条件式的每个分支上有着相同的一段代码,那么将这段重复代码搬移到条件之外。

 

 

 Remove Control Flag

 

状况:在一系列布尔表达式中,某个变量带有“控制标记”的作用,那么以break语句或return语句取代控制标记。

 

 

 

 

 Replace Nested Conditional with Guard Clauses

 

状况:函数中的条件逻辑使人很难看清正常的执行路径,那么使用卫语句(Guard Clauses)表现所有特殊情况。

条件式的两种形式:

  1、所有分支都属于正常行为:使用[if ... else..]

  2、条件式极其罕见:应该单独检查该条件,并在该条件为真时,立刻从函数中返回。——这样的单独检查常常被称为”卫语句“

Replace Nested Conditional with Guard Clauses精髓:给某一分支以特别重视。

 

 Replace Conditional with Polymorphism

 

状况:你手上有个表达式,它根据对象型别的不同而选择不同的行为,那么将这个条件式的每个分支放进一个subclass内的覆写函数中,然后将原始函数声明为抽象函数。

 

此代码的坏味道:

  1、它太长,当视频有新类型的时候,它会变得更长。

  2、它明显做了不止一件事。

  3、它违反了单一权责原则,因为它有好几个修改它的理由。

  4、它违反了开放闭合原则,因为每当添加新类型时,必须修改它。不过最麻烦的可能是到处皆有类似结构(_get类型名Rank())的函数。

 

 Introduce Assertion

 

状况:某一段代码需要对程序状态(state)做出某种假设,那么以断言(assertion)明确表现这种假设。

 

 

 

运行结果:

运行结果:

 

采点:

  1、常常会有这样的代码,只有当某个条件为真时,该段代码才能正常运行。——实际上程序最后成品往往将assertion统统删除。

  2、这样的假设通常并没有在代码中明确表现出来,你必须阅读整个算法才能看出。——有时候程序员会以注释写出这样的假设,而assetion是一种更好的技术。

  3、assertion是一个条件式,应该总是为真。如果失败,表示程序员犯了错误

  4、assertion可以作为交流与调试的辅助。——交流:可以帮助程序员阅读理解代码所做的假设。调试:帮助程序员找到bug,可以在距离最近的地方抓住bug。

  5、assertion并不改变程序的任何行为。

  6、assertion价值:帮助程序员理解代码正确运行的必要条件。

  7、建议最好把assertion的条件式使用Extract Method,为了将若干地方的重复码提炼到同一个函数中,也许只是为了更清楚说明条件式的用途。

 

 总结

 

       这一章我比较喜欢“Replace Nested Conditional with Guard Clauses “这个方式,我在平时的代码中也经常这样用,还有人给这种方式取名叫”卫从句“。

      还有一个就是我经常在php开发中用的调试是var_dump()或print_r(),我也第一次发现php中还有assert这种方式,不错!

 

        在学习和实践的过程中,我也学到了很多不错的方式。但是我觉得在团队开发中,有的时候还是”大局为重“,按照团队的习惯方式去编码,或者你可以跟团队沟通,得到大家的认可之后,在使用这里面的方法,这样大家彼此调试和阅读对方代码的时候比较方便。

时间: 2024-12-03 05:40:36

PHP 杂谈《重构-改善既有代码的设计》之四 简化条件表达式_php技巧的相关文章

PHP 杂谈《重构-改善既有代码的设计》之五 简化函数调用_php技巧

思维导图 介绍 前几篇系列文章,我比较关注的是<PHP 杂谈<重构-改善既有代码的设计>之一 重新组织你的函数>,但是我觉得我还是没有说清楚,我自己也有很多不理解的地方,而且这篇是我的第一篇这方面的文章,有很多的纰漏,所以我会经常性的去做修改,如果大家有好的意见不妨告知一.二. 今天谈得是"接口",此接口非"Interface",而是一个统称.我们一般可以把供别人使用的函数或者url(一般是用于提供数据)叫接口.--可能还有别的意思,毕竟我现

PHP 杂谈《重构-改善既有代码的设计》之三 重新组织数据_php技巧

思维导图 介绍    承接上文的PHP 杂谈<重构-改善既有代码的设计>之 重新组织你的函数继续重构方面的内容.   这章主要针对数据的重构.   1.争论的声音--直接访问Field还是通过函数(Accessor)访问Field  2.修改Array为Object:当你看到一个Array很像一个数据结构,你可以使用Replace Array with Object,把Array变成一个对象.--数据结构更清晰.      专业术语   accessor:访问者,存储器--在本文翻译为&quo

PHP 杂谈《重构-改善既有代码的设计》之二 对象之间搬移特性_php技巧

思维导图 索引: Ø Move Method(搬移函数) Ø Move Field (搬移值域) Ø Extract Class (提炼类) Ø Inline Class (将类内联化,就是把当前的类合并到其他类中) Ø Hide Delegate (隐藏委托关系) Ø Remove Middle Man ( 移除中间人) Ø Introduce Foreign Method (引入外加函数) Ø Introduce Local Extension (引入本地扩展)    介绍    承接上文P

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

思维导图 点击下图,可以看大图. 介绍 我把我比较喜欢的和比较关注的地方写下来和大家分享.上次我写了篇<php 跟老大的对话>.还是有很多疑问,这书帮了我不少的忙. 如果你比较繁忙,或者懒得看文字,建议你直接看截图,也会有很大的收获的.你可以通过比较截图中的代码就能知道孰优孰劣了. 代码部分我为什么用图呢?因为我经常用手机看代码,博客园的代码在手机里乱七八糟的,还是看图比较舒服. 专业术语 我们毕竟是用英文字母编码,所以用一些英语单词,更能显示出我们的专业性.以下的英文单词,你如果掌握了,与其

《重构:改善既有代码的设计》目录—导读

内容提要 重构:改善既有代码的设计 本书清晰揭示了重构的过程,解释了重构的原理和最佳实践方式,并给出了何时以及何地应该开始挖掘代码以求改善.书中给出了70 多个可行的重构,每个重构都介绍了一种经过验证的代码变换手法的动机和技术.本书提出的重构准则将帮助你一次一小步地修改你的代码,从而减少了开发过程中的风险. 本书适合软件开发人员.项目管理人员等阅读,也可作为高等院校计算机及相关专业师生的参考读物. 版权声明 重构:改善既有代码的设计 Authorized translation from the

《重构:改善既有代码的设计》—第1章1.1节起点

第1章 重构,第一个案例 重构:改善既有代码的设计 我该从何说起呢?按照传统做法,一开始介绍某个东西时,首先应该大致讲讲它的历史.主要原理等等.可是每当有人在会场上介绍这些东西,总是诱发我的瞌睡虫.我的思绪开始游荡,我的眼神开始迷离,直到主讲人秀出实例,我才能够提起精神.实例之所以可以拯救我于太虚之中,因为它让我看见事情在真正进行.谈原理,很容易流于泛泛,又很难说明如何实际应用.给出一个实例,就可以帮助我把事情认识清楚. 所以我决定从一个实例说起.在此过程中我将告诉你很多重构的道理,并且让你对重

《重构:改善既有代码的设计》—第2章2.1节何谓重构

第2章 重构原则 重构:改善既有代码的设计 前面所举的例子应该已经让你对重构有了一个良好的感受.现在,我们应该回头看看重构的关键原则,以及重构时需要考虑的某些问题. 2.1 何谓重构 我总是不太喜欢下定义,因为每个人对每样东西都有自己的定义.但是既然在写书,总得选择自己满意的定义.在重构这个概念上,我的定义以Ralph Johnson团队和其他相关研究成果为基础. 首先要说明的是:视上下文不同,"重构"这个词有两种不同的定义.你可能会觉得这挺烦人的(我就是这么想的),不过处理自然语言本

《重构:改善既有代码的设计》—重构列表

重构列表重构:改善既有代码的设计Add Parameter(添加参数) Change Bidirectional Association to Unidirectional(将双向关联改为单向关联) Change Reference to Value(将引用对象改为值对象) Change Unidirectional Association to Bidirectional(将单向关联改为双向关联) Change Value to Reference(将值对象改为引用对象) Collapse H

改善代码设计 简化条件表达式(Simplifying Conditional Expressions)

系列博客 1. 改善代码设计 -- 优化函数的构成(Composing Methods) 2. 改善代码设计 -- 优化物件之间的特性(Moving Features Between Objects) 3. 改善代码设计 -- 组织好你的数据(Composing Data) 4. 改善代码设计 -- 简化条件表达式(Simplifying Conditional Expressions) 5. 改善代码设计 -- 简化函数调用(Making Method Calls Simpler) 6. 改善