ThinkChat2.0新版上线,更智能更精彩,支持会话、画图、阅读、搜索等,送10W Token,即刻开启你的AI之旅 广告
### Decompose Conditional(分解条件式) 你有一个复杂的条件(if-then-else)语句。 从if、then、else 三个段落中分别提炼出独立函数。 ~~~ if (date.before (SUMMER_START) || date.after(SUMMER_END)) charge = quantity * _winterRate + _winterServiceCharge; else charge = quantity * _summerRate; ~~~ => ~~~ if (notSummer(date)) charge = winterCharge(quantity); else charge = summerCharge (quantity); ~~~ **动机(Motivation)** 程序之中,「复杂的条件逻辑」是最常导致复杂度上升的地点之一。你必须编写代码来检查不同的条件分支、根据不同的分支做不同的事,然后,你很快就会得到一个相当长的函数。大型函数自身就会使代码的可读性下降,而条件逻辑则会使代码更难阅读。在带有复杂条件逻辑的函数中,代码(包括检查条件分支的代码和真正实现功能的代码)会告诉你发生的事,但常常让你弄不清楚为什么会发生这样的事, 这就说明代码的可读性的确大大降低了。 和任何大块头代码一样,你可以将它分解为多个独立函数,根据每个小块代码的用 途,为分解而得的新函数命名,并将原函数中对应的代码替换成「对新建函数的调用」,从而更清楚地表达自己的意图。对于条件逻辑,[将每个分支条件分解,形成新函数」还可以给你带来更多好处:可以突出条件逻辑,更清楚地表明每个分支的作用,并且突出每个分支的原因。 **作法(Mechanics)** - 将if 段落提炼出来,构成一个独立函数。 - 将then 段落和else 段落都提炼出来,各自构成一个独立函数。 如果发现嵌套的(nested)条件逻辑,我通常会先观察是否可以使用Replace Nested Conditional with Guard Clauses 。如果不行,才开始分解其中的每个条件。 **范例(Example)** 假设我要计算购买某样商品的总价(总价=数量*单价),而这个商品在冬季和夏季的单价是不同的: ~~~ if (date.before (SUMMER_START) || date.after(SUMMER_END)) charge = quantity * _winterRate + _winterServiceCharge; else charge = quantity * _summerRate; ~~~ 我把每个分支的判断条件都提炼到一个独立函数中,如下所示: ~~~ if (notSummer(date)) charge = winterCharge(quantity); else charge = summerCharge (quantity); private boolean notSummer(Date date) { return date.before (SUMMER_START) || date.after(SUMMER_END); } private double summerCharge(int quantity) { return quantity * _summerRate; } private double winterCharge(int quantity) { return quantity * _winterRate + _winterServiceCharge; } ~~~ 通过这段代码你可以看出,整个重构带来的清晰性。实际工作中,我会逐步进行每一次提炼,并在每次提炼之后编译并测试。 像这样的情况下,许多程序员都不会去提炼分支条件。因为这些分支条件往往非常短,看上去似乎没有提炼的必要。但是,尽管这些条件往往很短,在代码意图和代 码自身之间往往存在不小的差距。哪怕在上面这样一个小小例子中,notSummer(date) 这个语句也能够比原本的代码更好地表达自己的用途。对于原来的代码,我必须看着它,想一想,才能说出其作用。当然,在我们这个简单的例子中,这并不困难。不过,即使如此,提炼出来的函数可读性也更高一些——它看上去就像一段注释那样清楚而明白。