GHawk

建議方正要是勝訴的話，為開(kāi)源事業(yè)做點(diǎn)貢獻(xiàn)

posted @ 2007-08-23 15:01 GHawk 閱讀(651) | 評(píng)論 (1) | 編輯 收藏

Maven2 用于度量和品質(zhì)保證的插件

• checkstyle 檢查編碼風(fēng)格
• 常用的goal
• checkstyle:checkstyle
• 備注
• 可以用eclipse-cs編輯檢查規(guī)則http://eclipse-cs.sourceforge.net/index.shtml
  

• surefire-report 生成單元測(cè)試報(bào)告
• 常用的goal
  
• surefire-report:report
  
• jdepend 生成包的度量報(bào)告
• 常用的goal
  
• jdepend:generate
  
• findbugs 檢查潛在的缺陷
• 常用的goal
  
• findbugs:findbugs
  
• cobertura 生成測(cè)試覆蓋率報(bào)告
• 常用的goal
  
• cobertura:cobertura
• 備注
• 直接從官方鏡像下載的版本有個(gè)bug，不能正確生成報(bào)告（參見(jiàn)http://jira.codehaus.org/browse/MCOBERTURA-61）可以下載補(bǔ)丁后的jar替換本地repository的
• jdk1.4對(duì)應(yīng)的補(bǔ)丁: http://dist.codehaus.org/mule/dependencies/maven2/cobertura/cobertura/1.8/cobertura-1.8.jar
• jdk5對(duì)應(yīng)的補(bǔ)丁:http://www.artofsolving.com/files/m2/cobertura-1.8.jar
  

posted @ 2007-05-28 14:32 GHawk 閱讀(1560) | 評(píng)論 (1) | 編輯 收藏

Scripting in Mustang 的一點(diǎn)啟發(fā)

//inline scripting
@ScriptBefore(script="",language="javascript"?)
public?void?foo()?{
???
}

//non-inline scripting
@ScriptBefore(file="scripts/logging.js",language="javascript")
public?void?bar()?{

}

posted @ 2006-09-26 10:04 GHawk 閱讀(1327) | 評(píng)論 (3) | 編輯 收藏

一個(gè)XPer提供的一些經(jīng)驗(yàn)

前些天，和一位XPer進(jìn)行了一次愉快的談話。他向我講述了一些感覺(jué)很有效的實(shí)踐。

posted @ 2006-08-24 15:45 GHawk 閱讀(1445) | 評(píng)論 (0) | 編輯 收藏

關(guān)于locale的設(shè)定 （轉(zhuǎn)）

posted @ 2006-08-16 10:45 GHawk 閱讀(757) | 評(píng)論 (0) | 編輯 收藏

PostgreSQL的主機(jī)認(rèn)證配置

posted @ 2006-06-07 10:42 GHawk 閱讀(1214) | 評(píng)論 (0) | 編輯 收藏

UP & XP之爭(zhēng)，意義何在？(續(xù))

雖然我沒(méi)能去參加BEA的活動(dòng)，但是相關(guān)的資料已經(jīng)下載并且瀏覽過(guò)了，確實(shí)收獲不少。所以，對(duì)于莊兄的這些想法我很理解。

相信不只你我，大部分的人都比較認(rèn)同敏捷化的過(guò)程，希望使過(guò)程變得敏捷。的確，這是個(gè)好東西，之前我也說(shuō)過(guò)“敏捷過(guò)程是三贏的”這樣的話。

我所關(guān)心的問(wèn)題是“如何能夠用好XP？”。

莊兄認(rèn)為“湯的味道，不需要什么過(guò)程控制”，我也會(huì)認(rèn)同。為什么？因?yàn)槟阄叶际侵袊?guó)人。大部分中國(guó)人不會(huì)認(rèn)為湯的味道需要什么過(guò)程控制。但是想想看，如果你在不同地方買(mǎi)到的肯德基炸雞味道各異；同一批次生產(chǎn)的同型號(hào)的汽車(chē)形狀各異；銀行里取出來(lái)的一疊百元大鈔大小不一，你不會(huì)覺(jué)得奇怪么或是有那么一點(diǎn)點(diǎn)憤怒么？

西方人（甚至學(xué)習(xí)西方的日本人）對(duì)品質(zhì)的重視程度卻完全不同。他們不允許肯德基炸雞的味道有很大偏差（即便你覺(jué)得無(wú)所謂）；“2毫米工程”不允許整車(chē)的總裝長(zhǎng)度發(fā)生2毫米以上的偏差（即便你覺(jué)得無(wú)所謂）；百元大鈔……（我想誰(shuí)都不會(huì)無(wú)所謂）。

所以，一切質(zhì)量都有標(biāo)準(zhǔn)，一切標(biāo)準(zhǔn)都應(yīng)該被度量！這就是工程學(xué)的目標(biāo)之一，為了實(shí)現(xiàn)更嚴(yán)格的質(zhì)量標(biāo)準(zhǔn)，就需要過(guò)程控制和度量。

莊兄所說(shuō)，用測(cè)試用例保證代碼的質(zhì)量其實(shí)還是采用了“測(cè)試用例”作為度量的標(biāo)準(zhǔn)。唯一的問(wèn)題是：“如何確保測(cè)試用例的質(zhì)量”。顯然，我們不能把一把不直的尺子度量出來(lái)的結(jié)果作為可靠的參考依據(jù)。怎么解決呢？“結(jié)對(duì)編程”么？嗯，這是一個(gè)不錯(cuò)的方式，那么最終該信賴誰(shuí)呢？是Pair中的A還是B呢？或者，是Leader么？那么又是誰(shuí)提出的要求呢？是老板么？還是客戶？政府？法規(guī)？市場(chǎng)？……問(wèn)題沒(méi)有終結(jié)了。

不要學(xué)習(xí)哲學(xué)家的方法，提出一層又一層無(wú)法解決的問(wèn)題。我們是工程師，應(yīng)該試圖解決問(wèn)題才對(duì)！解決問(wèn)題的關(guān)鍵在于，XP同樣需要標(biāo)準(zhǔn)！為了制定標(biāo)準(zhǔn)，必要的文檔是不可以少的。而且，標(biāo)準(zhǔn)本身的質(zhì)量是嚴(yán)苛的。因?yàn)椋鳛闃?biāo)準(zhǔn)，他不可以含糊其辭、模棱兩可。在標(biāo)準(zhǔn)的基礎(chǔ)之上，我們才可以談什么TDD、Pair Programming之類的實(shí)踐。

回到爭(zhēng)論的開(kāi)端。我引用了林先生的話“UP是正楷；XP是草書(shū)。要先學(xué)好UP才能學(xué)好XP，先學(xué)XP會(huì)亂套。”我對(duì)這句話的理解如下：這句話并沒(méi)有批判UP或是XP，只是指出了一個(gè)學(xué)習(xí)的順序。我認(rèn)為這句話是有實(shí)踐依據(jù)的，因?yàn)閁P強(qiáng)調(diào)的是一種經(jīng)典的工程方法。軟件工程本來(lái)就源于其他行業(yè)的工程實(shí)踐經(jīng)驗(yàn)。UP利用大量的文檔對(duì)開(kāi)發(fā)活動(dòng)進(jìn)行約束和記錄。正是這種重量級(jí)的過(guò)程規(guī)范了規(guī)范了從PM到Coder的所有活動(dòng)，有問(wèn)題可以參照文檔，看看自己應(yīng)該怎么做。文檔也可以作為日后評(píng)估這個(gè)過(guò)程的依據(jù)。隨著整個(gè)團(tuán)隊(duì)和每個(gè)個(gè)人的經(jīng)驗(yàn)不斷積累，開(kāi)發(fā)活動(dòng)中的日常行為漸漸形成了一種職業(yè)習(xí)慣。然后可以通過(guò)對(duì)UP的配置，逐漸減少文檔的使用量，一些沒(méi)有必要的文檔就可以省去，更具團(tuán)隊(duì)的實(shí)際能力調(diào)整過(guò)程。UP是可配置的，不必要的文檔沒(méi)有存在的理由，這一點(diǎn)UP和XP沒(méi)有什么兩樣。當(dāng)然，隨著大家的職業(yè)習(xí)慣越來(lái)越好，經(jīng)驗(yàn)越來(lái)越豐富，個(gè)人和團(tuán)隊(duì)就可以采用更敏捷更輕便的過(guò)程，逐漸過(guò)渡到XP上去。

反過(guò)來(lái)，如果一開(kāi)始就沒(méi)有詳盡的文檔，很多活動(dòng)（比如設(shè)計(jì)、版本控制）往往會(huì)脫離控制，進(jìn)入一種無(wú)序的、混亂的狀態(tài)。沒(méi)有文檔可參考，就意味著很多問(wèn)題只能問(wèn)人，而不同人的回答可能各異，同一個(gè)人對(duì)同一個(gè)問(wèn)題的兩次回答也可能不同！當(dāng)然，如果整個(gè)團(tuán)隊(duì)的工程素養(yǎng)和個(gè)體的職業(yè)習(xí)慣都比較好的情況下可能不會(huì)發(fā)生類似的情況。但是這種工程素養(yǎng)和職業(yè)習(xí)慣從哪里來(lái)，可能單靠的XP是不足以培養(yǎng)出來(lái)的。

“UP是正楷；XP是草書(shū)。要先學(xué)好UP才能學(xué)好XP，先學(xué)XP會(huì)亂套。”這句話表明了UP和XP在一定程度上是存在沖突的，并且提出了一條路線去降低和避免這個(gè)沖突。

再次需要強(qiáng)調(diào)的是莊兄所提到的“XP是一種思想”，這點(diǎn)我認(rèn)同。但是我認(rèn)為這個(gè)除了思想之外，還是一種“文化”。這種思想和文化也是出于軟件工程多年來(lái)的實(shí)踐，其中也不免有UP等其他過(guò)程。不能簡(jiǎn)單地認(rèn)為“我們只要吸取歷史的教訓(xùn)，提出新的思想和文化就不會(huì)再犯同樣的錯(cuò)誤了。”很多時(shí)候歷史總是一次又一次地重演著。新的思想和文化如果不能被準(zhǔn)確地理解和運(yùn)用，它所帶來(lái)的可能仍然是它原本想解決的問(wèn)題。只有我們具備了引入這種文化的基礎(chǔ)，才能把它變成自己的文化，否則這仍然是掛在嘴邊行于表面的一種不求精髓只求模仿的偽文化、偽思想。這一點(diǎn)對(duì)于UP和XP的實(shí)踐者來(lái)說(shuō)沒(méi)有什么兩樣。

posted @ 2006-04-25 15:03 GHawk 閱讀(2050) | 評(píng)論 (4) | 編輯 收藏

UP & XP之爭(zhēng)，意義何在？

不光是做軟件，凡是做產(chǎn)品，最后關(guān)注的總是產(chǎn)品的質(zhì)量。

舉個(gè)例子，比如你做一鍋湯：
今天你狀態(tài)很好，做完后嘗了嘗，感覺(jué)很美味，你的家人嘗了以后也有同感，喝完后感覺(jué)心情舒暢、意猶未盡。
隔了一個(gè)禮拜，你做同樣的湯給家里人喝。做完后你嘗了嘗，感覺(jué)依然美味，盼望著得到家人的賞識(shí)，然而他們卻說(shuō)味道咸了點(diǎn)。你很奇怪，為什么同樣自己嘗過(guò)了，家里人卻感覺(jué)不一樣呢？是不是最近加班多了，休息不好，味覺(jué)不準(zhǔn)了？
一個(gè)月過(guò)后，你要去國(guó)外出差，給家里請(qǐng)了個(gè)臨時(shí)保姆。一天，他也做了這么個(gè)湯，做完后，他也嘗了嘗，感覺(jué)口味很不錯(cuò)，可是端上桌，家里人說(shuō)這湯太辣了。原來(lái)這保姆才從湖南老家出來(lái)不久……

因此，只把焦點(diǎn)放在最后的產(chǎn)品上往往是不夠的。需要對(duì)“做湯的過(guò)程”加以控制。所以工程界會(huì)比較關(guān)注過(guò)程的管理，在軟件領(lǐng)域也稱作“軟件生命周期管理”。

再來(lái)看看UP和XP。它們都屬于軟件過(guò)程，只不過(guò)各有特色。

再拿剛才那個(gè)做湯的例子：
大家都聽(tīng)說(shuō)過(guò)德國(guó)人的廚房像化學(xué)實(shí)驗(yàn)室，天平、計(jì)時(shí)器、量杯……裝備齊全，再配上精確的菜譜，嚴(yán)謹(jǐn)?shù)牡聡?guó)人能夠確保不用嘗那最后一口都做出口味基本一致的湯。
換了中國(guó)人，大部分人都不會(huì)模仿德國(guó)人做菜的方式。解決方案很簡(jiǎn)單，讓你的太太和孩子都嘗那最后一口，再根據(jù)反饋調(diào)整幾次，同樣能做出全家人滿意的湯。

這個(gè)例子也許不太貼切，但是可以聯(lián)想一下:德國(guó)人做湯傾向于UP;中國(guó)人做湯傾向于XP。

UP和XP最終目的都是為了保證產(chǎn)品的質(zhì)量，不同的是，兩個(gè)過(guò)程所強(qiáng)調(diào)的方法不同。我想，沒(méi)有人會(huì)說(shuō)“UP的目的在于變態(tài)地追求文檔的完美”、“UP是為了要程序員學(xué)會(huì)寫(xiě)各種各樣文檔”……之類的話。同時(shí)，也沒(méi)人會(huì)說(shuō)“XP就是不要文檔只要代碼”、“XP就是要變態(tài)地追求完美的代碼”……這樣的話。

這些不正確的看法，只是人們對(duì)于這兩種過(guò)程的誤解。或許是來(lái)自于開(kāi)發(fā)人員和項(xiàng)目經(jīng)理的那些“不堪回首的經(jīng)歷”。

“UP害慘了整個(gè)軟件行業(yè)，讓開(kāi)發(fā)人員沒(méi)完沒(méi)了地寫(xiě)文檔而忽略了代碼，XP才是王道”這樣的話，我不敢茍同，仍然有很多企業(yè)使用著UP這樣的重型軟件工程，就好比德國(guó)人依然喜歡把廚房弄得像個(gè)實(shí)驗(yàn)室。

XP固然是個(gè)好東西。但是，不知道大多數(shù)人對(duì)于XP的熱衷是出于對(duì)XP文化的理解，還是國(guó)人慣有的“一窩蜂”似的行為。不曉得一個(gè)“能夠熟練閱讀代碼的Leader”是不是能夠真正運(yùn)用好XP，確保他的團(tuán)隊(duì)能夠盡可能少地出現(xiàn)"Over engineering"這種違背Agile精神的東西，或是能夠讓他的團(tuán)隊(duì)保證“每周只工作40小時(shí)”這樣的基本實(shí)踐？

對(duì)于不同的技術(shù)和過(guò)程，應(yīng)該給予冷靜的分析和慎重的選擇。每個(gè)過(guò)程和技術(shù)都不能以“正確”或“不正確”來(lái)定性，只能以“合適”和“不合適”來(lái)定性。因?yàn)檎_或不正確是要嚴(yán)格證明的，而合適不合適是來(lái)源于工程實(shí)踐的結(jié)果。所以，COBOL依然在金融領(lǐng)域起著舉足輕重的作用，科學(xué)家們?nèi)圆煌麱ortran，匯編和C仍然健在……

另外不得不提的是文化上的差異。為什么很多時(shí)候，我們學(xué)習(xí)國(guó)外的先進(jìn)技術(shù)，購(gòu)買(mǎi)了整套生產(chǎn)線，引進(jìn)了全套圖紙，請(qǐng)國(guó)外專家做了詳細(xì)的全程化培訓(xùn)，國(guó)人生產(chǎn)出的產(chǎn)品品質(zhì)依然不如國(guó)外原產(chǎn)的？這是每個(gè)中國(guó)人都應(yīng)該思考的問(wèn)題……

?

posted @ 2006-04-23 18:28 GHawk 閱讀(1900) | 評(píng)論 (4) | 編輯 收藏

對(duì)"UP是正楷，XP是草書(shū)"的反思

“UP是正楷，XP是草書(shū)。先學(xué)好了UP，才能學(xué)好XP；先學(xué)XP再學(xué)UP就會(huì)亂套。?”

老師曾這么說(shuō)。最近，對(duì)這句話有了深刻的體會(huì)。

軟件過(guò)程是一個(gè)以人為中心的活動(dòng)。人是項(xiàng)目中最難確定和控制的因素。休息的質(zhì)量、情緒的起伏都會(huì)影響整個(gè)活動(dòng)。為了盡可能地約束這種個(gè)體的不確定行為和減少開(kāi)發(fā)過(guò)程中不必要的誤會(huì)。"UP"采用了大量的文檔來(lái)對(duì)整個(gè)開(kāi)發(fā)過(guò)程進(jìn)行控制。這些文檔主要分為以下幾類：

• 計(jì)劃文檔——項(xiàng)目的開(kāi)發(fā)計(jì)劃、迭代計(jì)劃、測(cè)試計(jì)劃等。
• 技術(shù)文檔——項(xiàng)目的設(shè)計(jì)文檔、某個(gè)操作的說(shuō)明文檔等。
• 記錄文檔——日常的會(huì)議紀(jì)要、每日進(jìn)度反饋、評(píng)估報(bào)告等。

文檔成了UP活動(dòng)的主要部分。在UP中，往往大量的資源用于文檔的制作。這些文檔的目的是為了盡可能減少不必要的溝通成本和誤會(huì)，也為了在發(fā)生問(wèn)題的時(shí)候能夠盡快確定原因找到解決方法。

而正是因?yàn)槿绱朔敝氐馁Y源消耗，導(dǎo)致真正的設(shè)計(jì)和代碼只占到了總開(kāi)銷(xiāo)的很少部分。這對(duì)很多人來(lái)說(shuō)不可理解，甚至覺(jué)得本末倒置。于是很多敏捷方法誕生了，最具代表性也是對(duì)UP思想最具顛覆性的就屬XP了。

對(duì)外，XP以快速的反應(yīng)速度來(lái)響應(yīng)客戶的需求；對(duì)內(nèi)，XP以高質(zhì)量的代碼和設(shè)計(jì)來(lái)確保盡可能不產(chǎn)生不必要的文檔和資源開(kāi)銷(xiāo)。

從表面上看，在當(dāng)今，XP確實(shí)是一種非常理想的開(kāi)發(fā)過(guò)程。

但是，從沒(méi)有過(guò)程到XP往往會(huì)非常失敗。這是為什么？問(wèn)題的關(guān)鍵還在于人。

• 無(wú)過(guò)程-->UP -->XP

UP利用文檔來(lái)約束和規(guī)范人們的開(kāi)發(fā)活動(dòng)。當(dāng)一個(gè)沒(méi)有經(jīng)驗(yàn)的團(tuán)隊(duì)經(jīng)歷UP后，就等于把性格各異、習(xí)慣差別不同的人統(tǒng)一成了“相對(duì)較一致的開(kāi)發(fā)人員”。

他們有一致的編碼習(xí)慣，有共同的用語(yǔ)，有嚴(yán)格的規(guī)則。隨著經(jīng)驗(yàn)的積累，這個(gè)團(tuán)隊(duì)間的默契越來(lái)越高。此時(shí)，如果過(guò)程由UP向XP切換，付出的代價(jià)就會(huì)相對(duì)較低。

• 無(wú)過(guò)程-->XP-->UP

XP主張快速反應(yīng)。如果一個(gè)沒(méi)有經(jīng)驗(yàn)的團(tuán)隊(duì)在一開(kāi)始就嘗試XP，那么后果可能是慘痛的。因?yàn)橐粋€(gè)沒(méi)有經(jīng)驗(yàn)的團(tuán)隊(duì)其成員間的相互了解頗少，對(duì)于一件事，往往十個(gè)人有十種想法。當(dāng)缺少文檔約束時(shí)，在以代碼和設(shè)計(jì)為中心的活動(dòng)中，成員之間往往因?yàn)樗降膮⒉畈积R導(dǎo)致無(wú)休止的討論甚至爭(zhēng)論，代碼被不必要地頻繁改動(dòng)。這是因?yàn)椋?font color="#ff0000">在團(tuán)隊(duì)建設(shè)早期，成員之間往往連最基本的尊重和信任都不存在。 這種無(wú)意義的活動(dòng)往往會(huì)嚴(yán)重影響項(xiàng)目的正常進(jìn)行。

所以，學(xué)習(xí)和應(yīng)用過(guò)程不僅僅是個(gè)體的事，而是整個(gè)團(tuán)隊(duì)的事。只有當(dāng)團(tuán)隊(duì)采用嚴(yán)格文檔化的過(guò)程并且經(jīng)過(guò)磨合后，才能漸漸向輕量級(jí)的過(guò)程遷移，逐漸將不必要的文檔刪減掉，采用更靈活的過(guò)程。但是，此時(shí)并不是“沒(méi)有文檔”而是“心中有文檔”。

posted @ 2006-03-01 16:25 GHawk 閱讀(1656) | 評(píng)論 (4) | 編輯 收藏

加載Classpath中的文件（轉(zhuǎn)）

posted @ 2006-01-19 22:07 GHawk 閱讀(764) | 評(píng)論 (0) | 編輯 收藏

敏捷軟件開(kāi)發(fā) 讀書(shū)筆記 （4）——OO五大原則（3.LSP——里氏替換原則）

OCP作為OO的高層原則，主張使用“抽象(Abstraction)”和“多態(tài)(Polymorphism)”將設(shè)計(jì)中的靜態(tài)結(jié)構(gòu)改為動(dòng)態(tài)結(jié)構(gòu)，維持設(shè)計(jì)的封閉性。

“抽象”是語(yǔ)言提供的功能。“多態(tài)”由繼承語(yǔ)義實(shí)現(xiàn)。

如此，問(wèn)題產(chǎn)生了：“我們?nèi)绾稳ザ攘坷^承關(guān)系的質(zhì)量？”

Liskov于1987年提出了一個(gè)關(guān)于繼承的原則“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“繼承必須確保超類所擁有的性質(zhì)在子類中仍然成立。”也就是說(shuō)，當(dāng)一個(gè)子類的實(shí)例應(yīng)該能夠替換任何其超類的實(shí)例時(shí)，它們之間才具有is-A關(guān)系。

該原則稱為L(zhǎng)iskov Substitution Principle——里氏替換原則。林先生在上課時(shí)風(fēng)趣地稱之為“老鼠的兒子會(huì)打洞”。^_^

我們來(lái)研究一下LSP的實(shí)質(zhì)。學(xué)習(xí)OO的時(shí)候，我們知道，一個(gè)對(duì)象是一組狀態(tài)和一系列行為的組合體。狀態(tài)是對(duì)象的內(nèi)在特性，行為是對(duì)象的外在特性。LSP所表述的就是在同一個(gè)繼承體系中的對(duì)象應(yīng)該有共同的行為特征。

這一點(diǎn)上，表明了OO的繼承與日常生活中的繼承的本質(zhì)區(qū)別。舉一個(gè)例子：生物學(xué)的分類體系中把企鵝歸屬為鳥(niǎo)類。我們模仿這個(gè)體系，設(shè)計(jì)出這樣的類和關(guān)系。

類“鳥(niǎo)”中有個(gè)方法fly，企鵝自然也繼承了這個(gè)方法，可是企鵝不能飛阿，于是，我們?cè)谄簌Z的類中覆蓋了fly方法，告訴方法的調(diào)用者：企鵝是不會(huì)飛的。這完全符合常理。但是，這違反了LSP，企鵝是鳥(niǎo)的子類，可是企鵝卻不能飛！需要注意的是，此處的“鳥(niǎo)”已經(jīng)不再是生物學(xué)中的鳥(niǎo)了，它是軟件中的一個(gè)類、一個(gè)抽象。

有人會(huì)說(shuō)，企鵝不能飛很正常啊，而且這樣編寫(xiě)代碼也能正常編譯，只要在使用這個(gè)類的客戶代碼中加一句判斷就行了。但是，這就是問(wèn)題所在！首先，客戶代碼和“企鵝”的代碼很有可能不是同時(shí)設(shè)計(jì)的，在當(dāng)今軟件外包一層又一層的開(kāi)發(fā)模式下，你甚至根本不知道兩個(gè)模塊的原產(chǎn)地是哪里，也就談不上去修改客戶代碼了。客戶程序很可能是遺留系統(tǒng)的一部分，很可能已經(jīng)不再維護(hù)，如果因?yàn)樵O(shè)計(jì)出這么一個(gè)“企鵝”而導(dǎo)致必須修改客戶代碼，誰(shuí)應(yīng)該承擔(dān)這部分責(zé)任呢？（大概是上帝吧，誰(shuí)叫他讓“企鵝”不能飛的。^_^）“修改客戶代碼”直接違反了OCP，這就是OCP的重要性。違反LSP將使既有的設(shè)計(jì)不能封閉！

修正后的設(shè)計(jì)如下：

但是，這就是LSP的全部了么？書(shū)中給了一個(gè)經(jīng)典的例子，這又是一個(gè)不符合常理的例子：正方形不是一個(gè)長(zhǎng)方形。這個(gè)悖論的詳細(xì)內(nèi)容能在網(wǎng)上找到，我就不多廢話了。

LSP并沒(méi)有提供解決這個(gè)問(wèn)題的方案，而只是提出了這么一個(gè)問(wèn)題。

于是，工程師們開(kāi)始關(guān)注如何確保對(duì)象的行為。1988年，B. Meyer提出了Design by Contract（契約式設(shè)計(jì)）理論。DbC從形式化方法中借鑒了一套確保對(duì)象行為和自身狀態(tài)的方法，其基本概念很簡(jiǎn)單：

1. 每個(gè)方法調(diào)用之前，該方法應(yīng)該校驗(yàn)傳入?yún)?shù)的正確性，只有正確才能執(zhí)行該方法，否則認(rèn)為調(diào)用方違反契約，不予執(zhí)行。這稱為前置條件(Pre-condition)。
2. 一旦通過(guò)前置條件的校驗(yàn)，方法必須執(zhí)行，并且必須確保執(zhí)行結(jié)果符合契約，這稱之為后置條件(Post-condition)。
3. 對(duì)象本身有一套對(duì)自身狀態(tài)進(jìn)行校驗(yàn)的檢查條件，以確保該對(duì)象的本質(zhì)不發(fā)生改變，這稱之為不變式(Invariant)。

以上是單個(gè)對(duì)象的約束條件。為了滿足LSP，當(dāng)存在繼承關(guān)系時(shí)，子類中方法的前置條件必須與超類中被覆蓋的方法的前置條件相同或者更寬松；而子類中方法的后置條件必須與超類中被覆蓋的方法的后置條件相同或者更為嚴(yán)格。

一些OO語(yǔ)言中的特性能夠說(shuō)明這一問(wèn)題：

• 繼承并且覆蓋超類方法的時(shí)候，子類中的方法的可見(jiàn)性必須等于或者大于超類中的方法的可見(jiàn)性，子類中的方法所拋出的受檢異常只能是超類中對(duì)應(yīng)方法所拋出的受檢異常的子類。
  public class SuperClass{
      public void methodA() throws IOException{}
  }
  
  public class SubClassA extends SuperClass{
      //this overriding is illegal.
      private void methodA() throws Exception{}
  }
  
  public class SubClassB extends SuperClass{
      //this overriding is OK.
      public void methodA() throws FileNotFoundException{}
  }
  
  
• 從Java5開(kāi)始，子類中的方法的返回值也可以是對(duì)應(yīng)的超類方法的返回值的子類。這叫做“協(xié)變”(Covariant)
  
  public class SuperClass {
      public Number caculate(){
          return null;
      }
  }
  
  public class SubClass extends SuperClass{
      //only compiles in Java 5 or later.
      public Integer caculate(){
          return null;
      }
  }

可以看出，以上這些特性都非常好地遵循了LSP。但是DbC呢？很遺憾，主流的面向?qū)ο笳Z(yǔ)言（不論是動(dòng)態(tài)語(yǔ)言還是靜態(tài)語(yǔ)言）還沒(méi)有加入對(duì)DbC的支持。但是隨著AOP概念的產(chǎn)生，相信不久DbC也將成為OO語(yǔ)言的一個(gè)重要特性之一。

一些題外話：

前一陣子《敲響OO時(shí)代的喪鐘》和《喪鐘為誰(shuí)而鳴》兩篇文章引來(lái)了無(wú)數(shù)議論。其中提到了不少OO語(yǔ)言的不足。事實(shí)上，遵從LSP和OCP，不管是靜態(tài)類型還是動(dòng)態(tài)類型系統(tǒng)，只要是OO的設(shè)計(jì)，就應(yīng)該對(duì)對(duì)象的行為有嚴(yán)格的約束。這個(gè)約束并不僅僅體現(xiàn)在方法簽名上，而是這個(gè)具體行為的本身。這才是LSP和DbC的真諦。從這一點(diǎn)來(lái)說(shuō)并不能說(shuō)明“萬(wàn)事萬(wàn)物皆對(duì)象”的動(dòng)態(tài)語(yǔ)言和“C++，Java”這種“按接口編程”語(yǔ)言的優(yōu)劣，兩類語(yǔ)言都有待于改進(jìn)。莊兄對(duì)DJ的設(shè)想倒是開(kāi)始引入DbC的概念了。這一點(diǎn)還是非常值得期待的。^_^
另外，接口的語(yǔ)義正被OCP、LSP、DbC這樣的概念不斷地強(qiáng)化，接口表達(dá)了對(duì)象行為之間的“契約”關(guān)系。而不是簡(jiǎn)單地作為一種實(shí)現(xiàn)多繼承的語(yǔ)法糖。

posted @ 2006-01-18 18:12 GHawk 閱讀(3973) | 評(píng)論 (2) | 編輯 收藏

敏捷軟件開(kāi)發(fā) 讀書(shū)筆記 （3）——OO五大原則（2.OCP——開(kāi)閉原則）

開(kāi)閉原則很簡(jiǎn)單，一句話：“Closed for Modification; Open for Extension”——“對(duì)變更關(guān)閉；對(duì)擴(kuò)展開(kāi)放”。開(kāi)閉原則其實(shí)沒(méi)什么好講的，我將其歸結(jié)為一個(gè)高層次的設(shè)計(jì)總則。就這一點(diǎn)來(lái)講，OCP的地位應(yīng)該比SRP優(yōu)先。

OCP的動(dòng)機(jī)很簡(jiǎn)單：軟件是變化的。不論是優(yōu)質(zhì)的設(shè)計(jì)還是低劣的設(shè)計(jì)都無(wú)法回避這一問(wèn)題。OCP說(shuō)明了軟件設(shè)計(jì)應(yīng)該盡可能地使架構(gòu)穩(wěn)定而又容易滿足不同的需求。

為什么要OCP？答案也很簡(jiǎn)單——重用。

“重用”，并不是什么軟件工程的專業(yè)詞匯，它是工程界所共用的詞匯。早在軟件出現(xiàn)前，工程師們就在實(shí)踐“重用”了。比如機(jī)械產(chǎn)品，通過(guò)零部件的組裝得到最終的能夠使用的工具。由于機(jī)械部件的設(shè)計(jì)和制造過(guò)程是極其復(fù)雜的，所以互換性是一個(gè)重要的特性。一輛車(chē)可以用不同的發(fā)動(dòng)機(jī)、不同的變速箱、不同的輪胎……很多東西我們直接買(mǎi)來(lái)裝上就可以了。這也是一個(gè)OCP的例子。（可能是由于我是搞機(jī)械出身的吧，所以就舉些機(jī)械方面的例子^_^）。

如何在OO中引入OCP原則？把對(duì)實(shí)體的依賴改為對(duì)抽象的依賴就行了。下面的例子說(shuō)明了這個(gè)過(guò)程：

05賽季的時(shí)候，一輛F1賽車(chē)有一臺(tái)V10引擎。但是到了06賽季，國(guó)際汽聯(lián)修改了規(guī)則，一輛F1賽車(chē)只能安裝一臺(tái)V8引擎。車(chē)隊(duì)很快投入了新賽車(chē)的研發(fā)，不幸的是，從工程師那里得到消息，舊車(chē)身的設(shè)計(jì)不能夠裝進(jìn)新研發(fā)的引擎。我們不得不為新的引擎重新打造車(chē)身，于是一輛新的賽車(chē)誕生了。但是，麻煩的事接踵而來(lái)，國(guó)際汽聯(lián)頻頻修改規(guī)則，搞得設(shè)計(jì)師在“賽車(chē)”上改了又改，最終變得不成樣子，只能把它廢棄。

為了能夠重用這輛昂貴的賽車(chē)，工程師們提出了解決方案：首先，在車(chē)身的設(shè)計(jì)上預(yù)留出安裝引擎的位置和管線。然后，根據(jù)這些設(shè)計(jì)好的規(guī)范設(shè)計(jì)引擎（或是引擎的適配器）。于是，新的賽車(chē)設(shè)計(jì)方案就這樣誕生了。

顯然，通過(guò)重構(gòu)，這里應(yīng)用的是一個(gè)典型的Bridge模式。這個(gè)實(shí)現(xiàn)的關(guān)鍵之處在于我們預(yù)先給引擎留出了位置！我們不必因?yàn)閷?duì)引擎的規(guī)則的頻頻變更而制造相當(dāng)多的車(chē)身，而是盡可能地沿用和改良現(xiàn)有的車(chē)身。
說(shuō)到這里，想說(shuō)一說(shuō)OO設(shè)計(jì)的一個(gè)誤區(qū)。
學(xué)習(xí)OO語(yǔ)言的時(shí)候，為了能夠說(shuō)明“繼承”（或者說(shuō)“is-a”）這個(gè)概念，教科書(shū)上經(jīng)常用實(shí)際生活中的例子來(lái)解釋。比如汽車(chē)是車(chē)，電車(chē)是車(chē)，F(xiàn)1賽車(chē)是汽車(chē)，所以車(chē)是汽車(chē)、電車(chē)、F1賽車(chē)的上層抽象。這個(gè)例子并沒(méi)有錯(cuò)。問(wèn)題是，這樣的例子過(guò)于“形象”了！如果OO設(shè)計(jì)直接就可以將現(xiàn)實(shí)生活中的概念引用過(guò)來(lái)，那也就不需要什么軟件工程師了！OO設(shè)計(jì)的關(guān)鍵概念是抽象。如果沒(méi)有抽象，那所有的軟件工程師的努力都是徒勞的。因?yàn)槿绻麤](méi)有抽象，我們只能去構(gòu)造世界中每一個(gè)對(duì)象。上面這個(gè)例子中，我們應(yīng)該看到“引擎”這個(gè)抽象的存在，因?yàn)檐?chē)隊(duì)的工程師們?yōu)樗A(yù)留了位置，為它制定了設(shè)計(jì)規(guī)范。
上面這個(gè)設(shè)計(jì)也實(shí)現(xiàn)了后面要說(shuō)的DIP（依賴倒置原則）。但是請(qǐng)記住，OCP是OO設(shè)計(jì)原則中高層次的原則，其余的原則對(duì)OCP提供了不同程度的支持。為了實(shí)現(xiàn)OCP，我們會(huì)自覺(jué)或者不自覺(jué)地用到其它原則或是諸如Bridge、Decorator等設(shè)計(jì)模式。然而，對(duì)于一個(gè)應(yīng)用系統(tǒng)而言，實(shí)現(xiàn)OCP并不是設(shè)計(jì)目的，我們所希望的只是一個(gè)穩(wěn)定的架構(gòu)。所以對(duì)OCP的追求也應(yīng)該適可而止，不要陷入過(guò)渡設(shè)計(jì)。正如Martin本人所說(shuō)：“No significant program can be 100% closed.”“Closure not complete but strategic”

（下一篇就要講LSP了，我覺(jué)得這是意義最為重要的OO設(shè)計(jì)原則，它直指當(dāng)今主流OO語(yǔ)言的軟肋，點(diǎn)出了OO設(shè)計(jì)的精髓。）

posted @ 2006-01-18 00:26 GHawk 閱讀(7576) | 評(píng)論 (7) | 編輯 收藏

開(kāi)源 Java 測(cè)試框架（轉(zhuǎn)）

posted @ 2006-01-10 10:41 GHawk 閱讀(1247) | 評(píng)論 (0) | 編輯 收藏

敏捷軟件開(kāi)發(fā) 讀書(shū)筆記 （2）——OO五大原則（1.SRP 單一職責(zé)原則）

      一點(diǎn)說(shuō)明：OO的五大原則是指SRP、OCP、LSP、DIP、ISP。這五個(gè)原則是書(shū)中所提到的。除此之外，書(shū)中還提到一些高層次的原則用于組織高層的設(shè)計(jì)元素，這些放到下次再寫(xiě)。當(dāng)然，OO設(shè)計(jì)的原則可能不止這五個(gè)，希望大家多提寶貴意見(jiàn)，多多交流。

      在學(xué)習(xí)和使用OO設(shè)計(jì)的時(shí)候，我們應(yīng)該明白：OO的出現(xiàn)使得軟件工程師們能夠用更接近真實(shí)世界的方法描述軟件系統(tǒng)。然而，軟件畢竟是建立在抽象層次上的東西，再怎么接近真實(shí)，也不能替代真實(shí)或被真實(shí)替代。

      OO設(shè)計(jì)的五大原則之間并不是相互孤立的。彼此間存在著一定關(guān)聯(lián)，一個(gè)可以是另一個(gè)原則的加強(qiáng)或是基礎(chǔ)。違反其中的某一個(gè)，可能同時(shí)違反了其余的原則。因此應(yīng)該把這些原則融會(huì)貫通，牢記在心！

1. SRP（Single Responsibility Principle 單一職責(zé)原則）
      單一職責(zé)很容易理解，也很容易實(shí)現(xiàn)。所謂單一職責(zé)，就是一個(gè)設(shè)計(jì)元素只做一件事。什么是“只做一件事”？簡(jiǎn)單說(shuō)就是少管閑事。現(xiàn)實(shí)中就是如此，如果要你專心做一件事情，任何人都有信心可以做得很出色。但如果，你整天被亂七八糟的事所累，還有心思和精力把每件事都作好么？

     “單一職責(zé)”就是要在設(shè)計(jì)中為每種職責(zé)設(shè)計(jì)一個(gè)類，彼此保持正交，互不干涉。這個(gè)雕塑（二重奏）就是正交的一個(gè)例子，鋼琴家和小提琴家各自演奏自己的樂(lè)譜，而結(jié)果就是一個(gè)和諧的交響樂(lè)。當(dāng)然，真實(shí)世界中，演奏小提琴和彈鋼琴的必須是兩個(gè)人，但是在軟件中，我們往往會(huì)把兩者甚至更多攪和到一起，很多時(shí)候只是為了方便或是最初設(shè)計(jì)的時(shí)候沒(méi)有想到。 

      這樣的例子在設(shè)計(jì)中很常見(jiàn)，書(shū)中就給了一個(gè)很好的例子：調(diào)制解調(diào)器。這是一個(gè)調(diào)制解調(diào)器最基本的功能。但是這個(gè)類事實(shí)上完成了兩個(gè)職責(zé)：連接的建立和中斷、數(shù)據(jù)的發(fā)送和接收。顯然，這違反了SRP。這樣做會(huì)有潛在的問(wèn)題：當(dāng)僅需要改變數(shù)據(jù)連接方式時(shí)，必須修改Modem類，而修改Modem類的結(jié)果就是使得任何依賴Modem類的元素都需要重新編譯，不管它是不是用到了數(shù)據(jù)連接功能。解決的辦法，書(shū)中也已經(jīng)給出：重構(gòu)Modem類，從中抽出兩個(gè)接口，一個(gè)專門(mén)負(fù)責(zé)連接、另一個(gè)專門(mén)負(fù)責(zé)數(shù)據(jù)發(fā)送。依賴Modem類的元素也要做相應(yīng)的細(xì)化，根據(jù)職責(zé)的不同分別依賴不同的接口。最后由ModemImplementation類實(shí)現(xiàn)這兩個(gè)接口。

      從這個(gè)例子中，我們不難發(fā)現(xiàn)，違反SRP通常是由于過(guò)于“真實(shí)”地設(shè)計(jì)了一個(gè)類所造成的。因此，解決辦法是往更高一層進(jìn)行抽象化提取，將對(duì)某個(gè)具體類的依賴改變?yōu)閷?duì)一組接口或抽象類的依賴。當(dāng)然，這個(gè)抽象化的提取應(yīng)該根據(jù)需要設(shè)計(jì)，而不是盲目提取。比如剛才這個(gè)Modem的例子中，如果有必要，還可以把DataChannel抽象為DataSender和DataReceiver兩個(gè)接口。
 

posted @ 2006-01-09 21:17 GHawk 閱讀(5557) | 評(píng)論 (5) | 編輯 收藏