條件語句的作用是更改控制流,任何程式都離不開條件判斷。但條件判斷會增加程式的複雜度,過多的條件判斷會導致迴圈複雜度(cyclomatic complexity)。
這種複雜度取決於3個因素:
if
else if
else if
else if
switch
case 1:
...case 2:
...end switch
......
end if
end if
end if
end if
這種形狀也叫 arrow anti pattern。它不僅降低程式的可讀性,難以擴充套件和重用,還會輕易地隱藏許多bug。是我們必須避免的**。
設計模式注重於軟體的重用性和擴充套件性,但大多數模式都可以用來降低迴圈複雜度。設計模式可以讓不同參與者分擔這些條件語句,每個參與者解決一部分問題,這樣控制流程就更簡單,從而降低他們的迴圈複雜性。
這裡介紹乙個用策略(strategy)設計模式來降低迴圈複雜度的例子。
假設現在我們可以用 c# 寫乙個簡單的計算器,**如下:
using system;
public class calculator
else
break;
default:
throw new argumentexception("未知運算子: " + operater);
}return result;
}public static void main(string args)
;double operand1 = double.parse(args[0]);
double operand2 = double.parse(args[2]);
char operater = args[1][0];
double result = new calculator().calculate(operand1, operand2, operater);
console.writeline(operand1 + args[1] + operand2 + " = " + result);
console.readkey();}}
現在用策略模式來重構這段**:
模式角色:
strategy: iprocessor
concretestrategy: adder, subtractor, multiplier, divider
context: calculator
using system;
using system.collections.generic;
public inte***ce iprocessor
public class adder : iprocessor
}public class subtractor : iprocessor
}public class multiplier : iprocessor
}public class divider : iprocessor
else
return result;
}}public class calculator
public double calculate(double operand1, double operand2, string operater)
else
return result;
}public static void main(string args)
;if (args.length != 3)
else
catch (exception exp)
}console.readkey();}}
這裡針對不同的運算子使用相應的 processor 策略進行處理以實現計算目標,避免了迴圈巢狀( if / else ),也避免了最簡單的開關判斷(switch)。
本文討論了使用設計模式來降低迴圈複雜性的方法。通過使用設計模式重構具有更高迴圈複雜性的**可以帶來靈活,可配置和可擴充套件的系統。但是,由於需要更多的類相互協同工作,他們之間存在耦合,因此這種重構增加了解決方案的結構複雜性。因此,這些例子的應用可能更適合在條件語句可以從若干複雜分支中進行選擇的時候使用,而這些分支可能會隨時間而發生變化。這種變化可以是這些分支的數量以及每個分支內的功能。乙個典型的例子可能是資料通訊應用程式中的訊息接收器,它傳遞許多不同型別的訊息。每種訊息型別都可以由單獨的訊息處理程式處理。這些訊息處理程式可以按策略或責任鏈進行安排。不僅每個訊息處理程式的內聚性都更高,而且生成的應用程式還可以擴充套件以處理較新的訊息型別。
軟體設計的哲學 第八章 降低複雜性
目錄 本章介紹了另一種思考如何建立更深層次類的方法。假設您正在開發乙個新模組,並且發現了乙個不可避免的複雜性。哪個會更好呢 應該讓模組的使用者處理複雜性,還是應該在模組內部處理複雜性?如果複雜性與模組提供的功能有關,那麼第二個答案通常是正確的。大多數模組的使用者都比開發人員多,所以開發人員比使用者遭...
軟體設計的哲學 第八章 降低複雜性
目錄本章介紹了另一種思考如何建立更深層次類的方法。假設您正在開發乙個新模組,並且發現了乙個不可避免的複雜性。哪個會更好呢 應該讓模組的使用者處理複雜性,還是應該在模組內部處理複雜性?如果複雜性與模組提供的功能有關,那麼第二個答案通常是正確的。大多數模組的使用者都比開發人員多,所以開發人員比使用者遭罪...
破解軟體設計的複雜性
破解軟體設計的複雜性 在很多人眼裡,設計可能會顯得很神秘。其實設計和解題是一回事,只要把其中的規律弄清楚了,就能順應規律的指引自然而然的得出結論。只不過任何事情都是由前提條件的,設計的前提就是方 的指導加上廣泛的領域知識 不是指業務領域,對軟體設計來說就是軟體解決方案 生活中要做各種各樣的選擇,設計...