軟體最大的追求是什嗎？

　這段時間在開源領域，即將推出的Spring 2.0將支援非貧血模型，也就是說，Domain model的持久化可以乾淨地全部在Domain model自身之中實現了，這是物件導向技術一種探索。有關領域模型建模困惑可見這裡。　　

　　當物件導向技術正在將Model對象持久化行為綁定到Model資料自身時，工業界力推的SOA則倡導的是將資料從行為中解耦出來。SOA相關討論見這裡。看似矛盾，實際它們有一個共同點，追求同一個終極目標：松耦合（loose coupling）。

　　當我們在Java波濤洶湧的潮流中奮擊時，我們常常會思考？我為什麼要這樣做？甚至，我們會想松耦合真的那麼酷？可維護性真的是軟體唯一？也許我們迷失了方向。

　　我們要好好探究一下，軟體的最大追求是什嗎？

　　我們的大學電腦教育只是教會我們如何編程？這如同技工學校中教會學員如何使用車床一樣，當我們學會了編程，接下來是什麼呢？是不是就沒有了呢？是不是就是如同車工那樣只需日複一日的反覆編程呢？

　　其實，當你在一個系統中持續編程（增加新的東西），這個系統就變得複雜了，你面臨最大的挑戰是如何整理你自己的產物。

　　也就是說：大學教育只教會我們如何“增加新的東西”，但是沒有教育我們如何“整理這些東西”，而後者是目前軟體領域日新月異不斷髮生的革命的新動力。

　　下面我們以具體代碼來說明“增加新的東西”和“整理這些東西”完全屬於不同層次的學問，有些人談到軟體只會想到演算法和資料結構，認為這些才是科學，其實這是將軟體數學化，軟體不只是科學計算的工具，它自身也是一門科學，更象管理學/經濟學一樣，是科學和藝術的結合。

　　在最近Java(TM) Boutique網站上刊登出一篇文章Measuring the Complexity of OO Systems，衡量OO系統的複雜性，該文對軟體複雜性幾個著名公理進行了詳細闡述，這些公理如果你不進行學習和培訓，即使你使用OO語言Java等這樣工具，還是顯示你是“業餘”的。

　　軟體複雜性包括以下部分（引自Measuring the Complexity of OO Systems）：

• Cyclomatic Complexity （圈複雜性）
• Response for Class （類的響應）
• Weighted methods per class （每個類重量方法）

Cyclomatic Complexity

　　Cyclomatic Complexity可以用下面代碼來說明：

Cyclomatic Complexity (CC) = number of decision points +1

　　其中number of decision points是指一個if else之類的條件判斷語句，比如，是下面這個條語句：

public void isValidSearchCriteria(SearchCriteria s){ 　　if(s!=null) { 　　　　return true; 　　}else{ 　　　　return false; 　　} }

　　Cyclomatic complexity 對代碼的可測試性和可維護性上有很大影響，正如上例指出，當你要測試isValidSearchCriteria()方法 ，你必須寫三個測試案例來驗證它。

　　如果這個CC值增加，將有更多的判斷點（decision points）數量，也就意味著需要花費更多的力量來測試這些方法。詳細更多說明可參考Measuring the Complexity of OO Systems一文。

　　所以，if else 或while 等條件陳述式是對真正OO的一種傷害（這是非OO公理見Thomas McCabe），可以極端地說：一個好的OO系統幾乎在商務邏輯層看不到超出兩個以上條件的if else等判斷語句，這些條件陳述式都是可以被GoF設計模式的狀態模式/策略模式等替代（你還在用if else嗎）。

　　當你的Java系統中充滿了大量的if else語句，雖然你使用很酷的語言工具，但是說明你的思維是傳統過程的，需要重新學習和培訓。

Response for Class(RFC)

這是著名的 Chidamber and Kemerer公理之一。以下面代碼來說明：

public class RegistrationManager { 　　public void createRegistration(RegistrationData regData){ 　　　　DataAccessManager manager = new DataAccessManager(); 　　　　AuditManager auditManager = new AuditManager(); 　　　　//save the registration 　　　　manager.saveRegistration(regData); 　　　　//audit the creattion 　　　　auditManager.createAuditRecord(regData); 　　} 　　public Registration findRegistration(String regNumber){ 　　　　DataAccessManager manager = new DataAccessManager(); 　　　　Registration reg = null; 　　　　//find the registration 　　　　reg = manager.findRegsitration(regNumber); 　　　　return reg; 　　} }

　　這個類RegistrationManager 依賴其他兩個類DataAccessManager 和 AuditManager 。

　　按照公理公式：

　　RFC = M+ R (M = 這個類中方法個數. R = 其他總數)

　　在上例中，我們統計類響應RFC數目如下：

　　在RegistrationManager中方法數目 = 2
　　調用了DataAccessManager的方法數目 = 2
　　調用了AuditManager的方法數目 = 1

　　這樣：RFC(RegistrationManager) = 2 + 2 +1 = 5

　　當一個類和很多其他類存在依賴時，它就變得複雜甚至難以修改和維護，這樣，RFC值越大，表示你的系統味道越壞。

　　當然，因為OO系統是基於類和方法，不可能開發出一個0值RFC的系統，但是我們追求的目標是一種平衡，當你設計OO系統時，必須時刻注意這些公理，盡量避免類的編碼達到一個RFC高值。

　　我們如果使用現代一些模式：如Ioc模式，可以協助我們方便不費力氣地達到這樣一個平衡，因此，使用Spring/Jdon之類架構是降低RFC值的一個捷徑。

Weighted methods per class

　　之前幾個公理是介紹如何通過類之間互動調用使得軟體系統變得異常複雜，一個系統或一個特定的類自身也會變得異常複雜，有很多方法，Weighted Method Per Class公理協助我們量化定義這些情況。

　　這個公理定義會依據兩種情況：一個類實現；不同的實現。

　　WMC 1 = 一個類中所有方法個數.　　WMC 2 = 所有方法的Cyclomatic Complexities個數.

　　無論你選擇哪一種公式，一個WMC高值顯示這個類也許需要被重整成多個類。

　　這個公式可以協助你讓類保持乾淨，並且和相關行為意義上更加靠近（cohesive）。

　　以前面的RFC例子說明：如果你將DataAccessManager和AuditManager類中的方法都定義到當前RegistrationManager類中，你會得到一個WMC高值，這說明這個類需要重整了。

松耦合設計

　　前面章節我們反覆提到重整(refactoring)，它的意思就是：你不但會“增加新的東西”，而且還要學會“整理這些東西”（重整）。

　　正如兒童玩玩具一樣，他可以無師自通很快學會玩一個新東西，但是，當他玩完很多新玩具以後，他就很難學會整理他到處亂丟的玩具。由此可見：會編程不值得驕傲（可能源自天生），懂得如何整理才是真正的專業程式員。

　　現在，讓我們回到問題的本質，上述列舉了軟體的複雜性，複雜會導致難於維護和測試，那我們需要整理，那麼整理是否可量化一種程度呢？

　　我們使用“松耦合”這個概念來表示易於維護、易於測試、易於擴充的程度，當然，松耦合值越高，我們系統更易於維護。當前，軟體世界的發展，SOA、Ioc/AOP不都是在追求松耦合的最大化嗎？

　　松耦合一個反義詞“緊耦合”，從我們學會玩編程這個玩具開始起，我們就面臨兩種選擇：一種樸素的、無需訓練的、近似自然的“緊耦合”路線；一種是經過科學培訓的“松耦合”道路。選擇哪一條道路就取決於你是否受過專業訓練了。

　　所以，對於編程這個玩具，不在於你是否會玩，而在於你怎麼玩？玩的水平。如果不明白這個道理，中國軟體的蕭條永遠不會結束。