當(dāng)面向?qū)ο蠹夹g(shù)正在將Model對象持久化行為綁定到Model數(shù)據(jù)自身時，工業(yè)界力推的SOA則倡導(dǎo)的是將數(shù)據(jù)從行為中解耦出來。SOA相關(guān)討論見這里。看似矛盾，實際它們有一個共同點，追求同一個終極目標(biāo)：松耦合（loose coupling）。

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

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

　　我們的大學(xué)計算機(jī)教育只是教會我們?nèi)绾尉幊蹋窟@如同技工學(xué)校中教會學(xué)員如何使用車床一樣，當(dāng)我們學(xué)會了編程，接下來是什么呢？是不是就沒有了呢？是不是就是如同車工那樣只需日復(fù)一日的反復(fù)編程呢？

　　其實，當(dāng)你在一個系統(tǒng)中持續(xù)編程（增加新的東西），這個系統(tǒng)就變得復(fù)雜了，你面臨最大的挑戰(zhàn)是如何整理你自己的產(chǎn)物。

　　也就是說：大學(xué)教育只教會我們?nèi)绾巍霸黾有碌臇|西”，但是沒有教育我們?nèi)绾巍罢�理這些東西”，而后者是目前軟件領(lǐng)域日新月異不斷發(fā)生的革命的新動力。

　　下面我們以具體代碼來說明“增加新的東西”和“整理這些東西”完全屬于不同層次的學(xué)問，有些人談到軟件只會想到算法和數(shù)據(jù)結(jié)構(gòu)，認(rèn)為這些才是科學(xué)，其實這是將軟件數(shù)學(xué)化，軟件不只是科學(xué)計算的工具，它自身也是一門科學(xué)，更象管理學(xué)/經(jīng)濟(jì)學(xué)一樣，是科學(xué)和藝術(shù)的結(jié)合。

　　在最近Java(TM) Boutique網(wǎng)站上刊登出一篇文章Measuring the Complexity of OO Systems，衡量OO系統(tǒng)的復(fù)雜性，該文對軟件復(fù)雜性幾個著名公理進(jìn)行了詳細(xì)闡述，這些公理如果你不進(jìn)行學(xué)習(xí)和培訓(xùn)，即使你使用OO語言Java等這樣工具，還是顯示你是“業(yè)余”的。

　　軟件復(fù)雜性包括以下部分（引自Measuring the Complexity of OO Systems）：

Cyclomatic Complexity （圈復(fù)雜性） 
Response for Class （類的響應(yīng)） 
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 對代碼的可測試性和可維護(hù)性上有很大影響，正如上例指出，當(dāng)你要測試isValidSearchCriteria()方法 ，你必須寫三個測試用例來驗證它。

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

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