條件控制是編程中與生俱來的一種結(jié)構(gòu)，但對于我來說，除了給我?guī)砺闊┩猓瑳]有發(fā)現(xiàn)任何的用處。一次又一次，我不斷發(fā)現(xiàn)，越少的if語句，越少的 switch語句，越少的循環(huán)，就會是越好的代碼。通常這其中的原因是程序員用編程語言實現(xiàn)了更好的抽象歸納。他們并不是有意識的避免使用控制結(jié)構(gòu)。但他 們確實做到了這些。

如果是使用一種面向?qū)ο缶幊陶Z言，我們可以用多態(tài)(polymorphism)來代替switch。同樣的技巧也能用在 if語句上，但如果邏輯太簡單，這樣做就有點得不償失。當(dāng)使用一種有函數(shù)式特征的編程語言時，大部分的循環(huán)執(zhí)行任務(wù)我們都可以用 map，filter，fold等實現(xiàn)。控制結(jié)構(gòu)最終從代碼中消失，這是對代碼大有好處的事。

條件控制結(jié)構(gòu)的問題是，它很容易導(dǎo)致你把代碼修改的亂七八糟。讓我們看看下面一個簡單的if語句：

if ... 
    ... 
  else 
    ... 
  end  

代碼中所有打省略號的地方都是你可以不斷添加代碼的地方。這些地方可以訪問if外面的變量。這很容易造成高耦合。更糟糕的是，人們會習(xí)慣性的在條件 控制里嵌套條件。我見過的最糟糕的代碼，里面的嵌套之深的就像是噩夢里的無底洞。我想，條件控制結(jié)構(gòu)的真正問題所在是，它把各種任務(wù)混合到了一起。我相 信，你能從某種角度上看出，它是和任務(wù)單一編程原則相沖突的。

我們該怎么做？我們可不可以完全不要控制結(jié)構(gòu)？我想不行，但我們可以做一些實驗來看看如何能減少對它們的使用。通常這樣做會讓我們從中學(xué)到一些新技巧，讓我們的代碼更整潔。

不久前，我開發(fā)了一些Ruby程序，我需要寫一個‘take’函數(shù)，用它從一個數(shù)組里取出一些元素。Ruby里有一些針對Enumerable的這樣的函數(shù)，但我需要一些特殊的功能。如果我需要的數(shù)組的大小超出了目標(biāo)數(shù)組的大小，需要把多余的數(shù)組空間都置為0。

這看起來可以用簡單的if語句實現(xiàn)：

def padded_take ary, n 
   if n <= ary.length 
     ary.take(n) 
   else 
     ary + [0] * (n - ary.length) 
   end 
 end 

讓我們認(rèn)真的看一看這段代碼。它沒有向我們顯示任何填充動作的信息，沒有顯示數(shù)組跟填充的關(guān)系。如果認(rèn)真看，可以看出其中的邏輯，但我們看不出這段代碼的意圖。

我們引入一些函數(shù)來讓這段代碼更清楚些，使用guard語句來簡化if語句：

def padded_take ary, n 
   return ary.take(n) unless needs_padding?(ary, n) 
   ary + pad(ary, n) 
 end 

這個短小精悍，但不是更簡單——我們可以使用一個null對象來去掉條件語句。空的數(shù)組就是很好的null對象。讓我們在來一次。

我們不需要用一個條件語句來計算填充的長度。這個長度我們可以取兩個數(shù)組中的***值，如果我們想要的長度超出了數(shù)組的長度，填充的長度就是它們的差值：

pad_length = [0, n - ary.length].max 

有了這個長度，我們可以先填充數(shù)組，然后取出我們想要的元素：

def pad ary, n 
   pad_length = [0, n - ary.length].max 
   ary + [0] * pad_length 
 end 

于是，我們可以這樣定義取出動作：

def padded_take ary, n 
    pad(ary, n).take(n) 
  end 

我們通過先進(jìn)行填充從而避免了使用if語句。當(dāng)然，有時候填充的是一個空數(shù)組。

我不想去爭論這樣的寫法是否比最初的if-then-else代碼更簡單，但現(xiàn)在的代碼的意圖更清晰了，而且我不認(rèn)為這種策略在這種代碼里使用是過度技術(shù)化。

從提取歸納的層面看，代碼經(jīng)過處理后的好處是明顯的。當(dāng)遇到更復(fù)雜問題時，它帶來的益處將會更明顯。

原文鏈接：http://michaelfeathers.typepad.com/michael_feathers_blog/2013/11/unconditional-programming.html

譯文鏈接：http://www.aqee.net/unconditional-programming/