每當看到乙個方法中有幾百行**，裡面被層層的if else所包圍，我都感嘆，為什麼我們不能對if else優化一下呢？早些年，table很流行，搭建頁面框架比較簡單，但是慢慢人們發現層層的巢狀，卻並不利於**的閱讀，於是人們發明了div來代替table。if else儘管處理業務邏輯比較簡單，但是層層的巢狀卻不利於**的閱讀，而且降低了系統的效率，為什麼我們不能優化一下if else呢？
其實，優化if else很簡單，只需三招即可搞定。
第一招：將滿足判斷條件更高的結構寫在前面。因為if else每執行一段**，都要判斷條件是否滿足，如果不滿足，則向下繼續尋找滿足的條件，直到找到符合的條件或者if結構結束。因此， 將滿足判斷條件更高的結構寫在前面 ，就會減少條件的判斷，降低系統執行的時間，提高系統的效率。在某些情況下，使用switch的效率要比if else高，因為switch條件不會重複的進行條件判斷。
第二招：使用二分法進行條件判斷。嚴格來說，使用二分法並不能降低程式的執行次數，只是對於那些條件符合判定的概率大致相同的情況下，能夠降低平均查詢時間。在寫程式時，這樣的條件基本上不會遇到，不過這裡還是給出示例**，希望朋友們在遇到這種情況下，知道有一種二分法可以降低平均查詢次數。
示例**如下：
getproperty : function(key)
halfgetproperty : function(key)
第三招：使用陣列或者配置檔案優化系統結構。每當看到乙個長達幾千行的**中，充斥著無數個if else，我都想吐。雖然這些結構都比較類似，但是由於**段長度過長，已經失去了可讀性。每當需要修改**的時候，都要去那幾千行**中找到自己對應的if結構，費時又費力，而且更改的風險還特別高。
如果我們採用配置檔案或者陣列來處理這些差異的部分，就會發現類的結構就會變得聚合度特別強，而耦合度特別低，而且**的可讀性特別高，如果有需要更改的地方，很快就能定位到相關的**。
下面的**是載入表單的乙個例子，因為要保持系統結構的一致性，很多模組重用了乙個介面，但是我們要根據不同的業務，對表單上的內容（tab頁和buttons）做不同的顯示。通過**我們就能夠看出在當前的**情況下，如果有新需求增加進來，仍然要重用這個介面，更改起來的差異有多大。
//原來載入表單的方法
init : function(type)
//使用陣列載入表單
var config =
//構建當前業務模組的介面顯示
initconfig : function(type)
//根據配置，構建當前業務模組所需的tabcontent
buildtabcontainer : function(type),
//根據配置，構建當前業務模組所需的功能buttons
buildbuttons : function(type),
_createtabcontentpane : function(tabcontentname),
_buildbutton : function(buttonname),
重構優化if else
背景說明 隨著業務邏輯越來越多,if else也越來越長,所以就想重新優化一下,看了一下資料,寫了一點偽 記錄一下自己的體會.場景說明 不同的支付型別對應不同的支付型別的業務處理邏輯.1.直接使用if else處理業務邏輯 public static void main string args if...
策略模式優化大量if else
在 編寫的個過程中難免會碰到使用到if else的情況，太多的if else會使 變的臃腫並且難以理解，然後想到了之前寫策略模式是可以對它進行優化的，的規範和易懂性我認為對乙個優秀程式設計師來說是必要的。平常經常碰到的 author cjd description 使用if.else臃腫的 retu...
if else 優化之 策略模式
在策略模式 strategy pattern 中，乙個類的行為或其演算法可以在執行時更改。這種型別的設計模式屬於行為型模式。在策略模式中，我們建立表示各種策略的物件和乙個行為隨著策略物件改變而改變的 context 物件。策略物件改變 context 物件的執行演算法。業務處理主服務類 servic...