牛仔褲的夏天

??? 貝貝在宜城中心幼兒園的第一個“六一”國際兒童節終于來到了，這對于我們全家來說可是一個大日子。早上起來，貝貝卻有點擔心我們不陪他一起參加幼兒園的慶祝活動，從而流露出一絲焦慮。其實我們才不會錯過這個難得的機會呢，更何況爸爸媽媽和貝貝一起準備的歌舞“小海軍”，也將在今天的慶祝活動中一起亮相呢。

?????? 早上九點，我們準時來到幼兒園。作為小朋友們的樂園，這里歡歌笑語，張燈結彩，處處洋溢著兒童節的歡快氣氛，貝貝也很快就融入到節日的氛圍之中了。

在陸老師和潘老師井然有序的安排下，小一班的慶祝活動開始了。小朋友們分組表演了兒歌和童謠。輪到貝貝這一組開始表演了，我們趕快準備拍照和攝像，一定要把這精彩的瞬間捕捉記錄下來。“ … 公雞每天早早起，母雞生蛋孵小雞 …” ，小朋友們花朵般幼嫩的歌喉伴隨著可愛的舞蹈動作吸引了在場的每一位家長。當我們還都沉浸在剛才精彩的幼兒歌舞表演時，家長們的趣味游戲“水果蹲”開始了，我和貝貝媽媽也積極參與了這個游戲。家長們的表現讓小朋友們忍俊不止，“咯咯咯 … 咯咯咯”，一串串的笑聲渲染了每一位大人和小朋友。

貝貝今天的表現很棒，當陸老師說請貝貝家庭表演歌舞“小海軍”時，他很快就大大方方地跑到舞臺中央，聲音響亮，和爸爸一起唱起小海軍這首兒歌，同時動作流暢，和媽媽一起跳著舞蹈，開開心心地完成了這個節目，贏得了大家的一片掌聲。我們一直都很珍惜與貝貝一同參加集體活動的機會，因此心中尤為以這次在幼兒園里和貝貝一起同臺表演而感到高興。接下來，其他的家庭也都表演了各自精彩的節目，有講故事、鋼琴獨奏、雙簧，還有魔術，眾彩紛呈的節目把這次活動的氣氛推向高潮。以至于活動落下帷幕時，家長和小朋友們都還戀戀不舍呢。

回家后，貝貝蹦蹦跳跳，不時唱著兒歌，似乎還對今天的活動意猶未盡。“六一”兒童節，我們全家過得開心而有意義。通過這次活動增強了貝貝在集體活動中的自信心和責任感，同時也加強了我們和貝貝之間的互動體驗。

1
早上，貝貝站在我的摩托車踏板上，我送他去幼兒園。開到roundabout的地方時，貝貝說：爸爸就開這個溫度吧。 我問：什么？ 貝貝說：是速度，不要再加速度了。

2
貝貝喜歡打電腦游戲，前幾天特別喜歡玩一個哆啦A夢釣魚的flash游戲，如果不小心會釣到鯊魚，而且我們不讓他多玩。一天貝貝睡覺做夢而大哭，叫醒后問他做到什么夢了，他說：爸爸不讓我玩釣魚，而且釣到了鯊魚把小貓吃掉了。

3
晚上吃櫻桃，貝貝吃的很開心，還挑出紅的給我吃。我對貝貝說：挑1粒給媽媽吃吃，去拍拍她的馬屁。于是貝貝選了一個紅的櫻桃，跑到媽媽邊上說：媽媽，喏，吃個馬屁。

1. 域模型也稱為設計模型，由以下內容組成：
??? 具有狀態和行為的域對象
??? 域對象之間的關系

2. 域對象(Domain Object) - 對真實世界的實體的軟件抽象，也叫業務對象(Business Object)，分為：
????實體域對象(實體EJB，POJO)，為每個實體域對象分配OID(Object Identifier)
????過程域對象(Session Bean, Message Driven Bean, Java Bean)
??? 事件域對象(事件觸發)
? 三種域對象位于業務邏輯層

3. 域對象之間的關系
??? 關聯(Association)：one to one, one to many, many to many, 單向, 雙向
??? 依賴(Dependency)：類與類之間的訪問關系，如果A訪問B的屬性或者方法，或者A負責實例化B，則A依賴B。過程域對象往往依賴實體域對象。
????聚集(Aggregation)：整體與部分之間的關系，實體域對象之間常見。聚集關系和關聯關系有相同的形式，區別是：對于聚集關系，部分類的對象不能單獨存在，它的生命周期依賴于整體類的對象的生命周期；對于關聯關系的2個類，可以分別單獨存在。
????一般化(Generalization)

?????
???

這2天用hsqldb做hibernate測試，做insert時，不論用hibernate的方法還是用jdbc的方法，顯示的一切信息都是成功的，可是后來打開hsqldb的manager，發現table里面沒有記錄insert，郁悶之極，覺得應該是hsqldb的配置問題

于是打開那個script文件，最后找到這句配置：SET WRITE_DELAY 20
改為SET WRITE_DELAY 0后，一切正常了

我對decorate模式的理解：
1-首先要有一個Interface，提供一個通用的方法；
2-其次有n多個class來實現這個接口中的方法，這些實現方法在功能上應該是并列的，但不是必須的，從而可以根據需要decorate那個需要被修飾的初始對象。
3-最后這些class都有一個帶有Interface作為參數的構造方法和一個Interface的屬性，這樣在構造的時候就可以取得那個需要修飾的對象的實例，然后在實現Interface的方法里面，首先實現修飾對象實例的修飾方法，然后再進行自己的decorate方法。

根據這個想法來畫一張畫：

再寫段測試畫畫的代碼:

測試結果:

?最后有個問題：為什么不直接定義一個畫畫的類，然后把這些該怎么畫的事情分別通過方法來實現呢？ 那么什么情況下使用decorate模式更為合適呢？

你覺得自己是一個Java專家嗎？是否肯定自己已經全面掌握了Java的異常處理機制？在下面這段代碼中，你能夠迅速找出異常處理的六個問題嗎？

??????? 1 OutputStreamWriter out = ...
　　2 java.sql.Connection conn = ...
　　3 try { // ⑸
　　4 Statement stat = conn.createStatement();
　　5 ResultSet rs = stat.executeQuery(
　　6 "select uid, name from user");
　　7 while (rs.next())
　　8 {
　　9 out.println("ID：" + rs.getString("uid") // ⑹
　　10 "，姓名：" + rs.getString("name"));
　　11 }
　　12 conn.close(); // ⑶
　　13 out.close();
　　14 }
　　15 catch(Exception ex) // ⑵
　　16 {
　　17 ex.printStackTrace(); // ⑴，⑷
　　18 }

作為一個Java程序員，你至少應該能夠找出兩個問題。但是，如果你不能找出全部六個問題，請繼續閱讀本文。

本文討論的不是Java異常處理的一般性原則，因為這些原則已經被大多數人熟知。我們要做的是分析各種可稱為“反例”（anti-pattern）的違背優秀編碼規范的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而能夠在實際工作中敏銳地察覺和避免這些問題。

反例之一：丟棄異常

代碼：15行-18行。

這段代碼捕獲了異常卻不作任何處理，可以算得上Java編程中的殺手。從問題出現的頻繁程度和禍害程度來看，它也許可以和C/C++程序的一個惡名遠播的問題相提并論??不檢查緩沖區是否已滿。

如果你看到了這種丟棄（而不是拋出）異常的情況，可以百分之九十九地肯定代碼存在問題（在極少數情況下，這段代碼有存在的理由，但最好加上完整的注釋，以免引起別人誤解）。

這段代碼的錯誤在于，異常（幾乎）總是意味著某些事情不對勁了，或者說至少發生了某些不尋常的事情，我們不應該對程序發出的求救信號保持沉默和無動于衷。調用一下printStackTrace算不上“處理異常”。

不錯，調用printStackTrace對調試程序有幫助，但程序調試階段結束之后，printStackTrace就不應再在異常處理模塊中擔負主要責任了。

丟棄異常的情形非常普遍。打開JDK的ThreadDeath類的文檔，可以看到下面這段說明：“特別地，雖然出現ThreadDeath是一種‘正常的情形’，但ThreadDeath類是Error而不是Exception的子類，因為許多應用會捕獲所有的Exception然后丟棄它不再理睬。

”這段話的意思是，雖然ThreadDeath代表的是一種普通的問題，但鑒于許多應用會試圖捕獲所有異常然后不予以適當的處理，所以JDK把ThreadDeath定義成了Error的子類，因為Error類代表的是一般的應用不應該去捕獲的嚴重問題。可見，丟棄異常這一壞習慣是如此常見，它甚至已經影響到了Java本身的設計。

那么，應該怎樣改正呢？主要有四個選擇：

1、處理異常。針對該異常采取一些行動，例如修正問題、提醒某個人或進行其他一些處理，要根據具體的情形確定應該采取的動作。再次說明，調用printStackTrace算不上已經“處理好了異常”。

2、重新拋出異常。處理異常的代碼在分析異常之后，認為自己不能處理它，重新拋出異常也不失為一種選擇。

3、把該異常轉換成另一種異常。大多數情況下，這是指把一個低級的異常轉換成應用級的異常（其含義更容易被用戶了解的異常）。

4、不要捕獲異常。

結論一：既然捕獲了異常，就要對它進行適當的處理。不要捕獲異常之后又把它丟棄，不予理睬。

反例之二：不指定具體的異常

代碼：15行。

許多時候人們會被這樣一種“美妙的”想法吸引：用一個catch語句捕獲所有的異常。最常見的情形就是使用catch(Exception

ex)語句。但實際上，在絕大多數情況下，這種做法不值得提倡。為什么呢？

要理解其原因，我們必須回顧一下catch語句的用途。catch語句表示我們預期會出現某種異常，而且希望能夠處理該異常。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常。

由于絕大多數異常都直接或間接從java.lang.Exception派生，catch(Exception ex)就相當于說我們想要處理幾乎所有的異常。

再來看看前面的代碼例子。我們真正想要捕獲的異常是什么呢？最明顯的一個是SQLException，這是JDBC操作中常見的異常。另一個可能的異常是IOException，因為它要操作OutputStreamWriter。

顯然，在同一個catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個catch塊分別捕獲SQLException和IOException就要好多了。這就是說，catch語句應當盡量指定具體的異常類型，而不應該指定涵蓋范圍太廣的Exception類。

另一方面，除了這兩個特定的異常，還有其他許多異常也可能出現。例如，如果由于某種原因，executeQuery返回了null，該怎么辦？答案是讓它們繼續拋出，即不必捕獲也不必處理。實際上，我們不能也不應該去捕獲可能出現的所有異常，程序的其他地方還有捕獲異常的機會直至最后由JVM處理。

結論二：在catch語句中盡可能指定具體的異常類型，必要時使用多個catch。不要試圖處理所有可能出現的異常。

反例之三：占用資源不釋放

代碼：3行-14行。

異常改變了程序正常的執行流程。這個道理雖然簡單，卻常常被人們忽視。如果程序用到了文件、Socket、JDBC連接之類的資源，即使遇到了異常，也要正確釋放占用的資源。為此，Java提供了一個簡化這類操作的關鍵詞finally。

finally是樣好東西：不管是否出現了異常，Finally保證在try/catch/finally塊結束之前，執行清理任務的代碼總是有機會執行。遺憾的是有些人卻不習慣使用finally。

當然，編寫finally塊應當多加小心，特別是要注意在finally塊之內拋出的異常??這是執行清理任務的最后機會，盡量不要再有難以處理的錯誤。

結論三：保證所有資源都被正確釋放。充分運用finally關鍵詞。

反例之四：不說明異常的詳細信息

代碼：3行-18行。

仔細觀察這段代碼：如果循環內部出現了異常，會發生什么事情？我們可以得到足夠的信息判斷循環內部出錯的原因嗎？不能。我們只能知道當前正在處理的類發生了某種錯誤，但卻不能獲得任何信息判斷導致當前錯誤的原因。

printStackTrace的堆棧跟蹤功能顯示出程序運行到當前類的執行流程，但只提供了一些最基本的信息，未能說明實際導致錯誤的原因，同時也不易解讀。

因此，在出現異常時，最好能夠提供一些文字信息，例如當前正在執行的類、方法和其他狀態信息，包括以一種更適合閱讀的方式整理和組織printStackTrace提供的信息。

結論四：在異常處理模塊中提供適量的錯誤原因信息，組織錯誤信息使其易于理解和閱讀。

反例之五：過于龐大的try塊

代碼：3行-14行。

經常可以看到有人把大量的代碼放入單個try塊，實際上這不是好習慣。這種現象之所以常見，原因就在于有些人圖省事，不愿花時間分析一大塊代碼中哪幾行代碼會拋出異常、異常的具體類型是什么。把大量的語句裝入單個巨大的try塊就象是出門旅游時把所有日常用品塞入一個大箱子，雖然東西是帶上了，但要找出來可不容易。

一些新手常常把大量的代碼放入單個try塊，然后再在catch語句中聲明Exception，而不是分離各個可能出現異常的段落并分別捕獲其異常。這種做法為分析程序拋出異常的原因帶來了困難，因為一大段代碼中有太多的地方可能拋出Exception。

結論五：盡量減小try塊的體積。

反例之六：輸出數據不完整

代碼：7行-11行。

不完整的數據是Java程序的隱形殺手。仔細觀察這段代碼，考慮一下如果循環的中間拋出了異常，會發生什么事情。循環的執行當然是要被打斷的，其次，catch塊會執行??就這些，再也沒有其他動作了。

已經輸出的數據怎么辦？使用這些數據的人或設備將收到一份不完整的（因而也是錯誤的）數據，卻得不到任何有關這份數據是否完整的提示。對于有些系統來說，數據不完整可能比系統停止運行帶來更大的損失。

較為理想的處置辦法是向輸出設備寫一些信息，聲明數據的不完整性；另一種可能有效的辦法是，先緩沖要輸出的數據，準備好全部數據之后再一次性輸出。

結論六：全面考慮可能出現的異常以及這些異常對執行流程的影響。

改寫后的代碼

根據上面的討論，下面給出改寫后的代碼。也許有人會說它稍微有點?嗦，但是它有了比較完備的異常處理機制。


OutputStreamWriter out = ...
　　java.sql.Connection conn = ...
　　try {
　　　Statement stat = conn.createStatement();
　　　ResultSet rs = stat.executeQuery("select uid, name from user");
　　　while (rs.next()){
　　　　out.println("ID：" + rs.getString("uid") + "，姓名: "+ rs.getString("name"));
　　　}
　　}
　　catch(SQLException sqlex)
　　{
　　　out.println("警告：數據不完整");
　　　throw new ApplicationException("讀取數據時出現SQL錯誤", sqlex);
　　}
　　catch(IOException ioex)
　　{
　　　throw new ApplicationException("寫入數據時出現IO錯誤", ioex);
　　}
　　finally
　　{
　　　if (conn != null) {
　　　　try {
　　　　　conn.close();
　　　　}
　　　　catch(SQLException sqlex2)
　　　　{
　　　　　System.err(this.getClass().getName() + ".mymethod - 不能關閉數據庫連接:" + sqlex2.toString());
　　　　}
　　　}
　　　if (out != null){
　　　　try {
　　　　　out.close();
　　　　}
　　　　catch(IOException ioex2)
　　　　{
　　　　　System.err(this.getClass().getName() + ".mymethod - 不能關閉輸出文件" + ioex2.toString());
　　　　}
　　　}
　　}




本文的結論不是放之四海皆準的教條，有時常識和經驗才是最好的老師。如果你對自己的做法沒有百分之百的信心，務必加上詳細、全面的注釋。

一方面，不要笑話這些錯誤，不妨問問你自己是否真地徹底擺脫了這些壞習慣。即使最有經驗的程序員偶爾也會誤入歧途，原因很簡單，因為它們確確實實帶來了“方便”。所有這些反例都可以看作Java編程世界的惡魔，它們美麗動人，無孔不入，時刻誘惑著你。也許有人會認為這些都屬于雞皮蒜毛的小事，不足掛齒，但請記住：勿以惡小而為之，勿以善小而不為。

• name : 指定ActionMessages存放在request或者session內的屬性key.
• message: 指定消息的來源, 如果為true, 對應于key=Globals.MESSAGE_KEY的ActionMessages對象, 此時name屬性無效；如果為false, 則根據name屬性檢索ActionMessages對象, 如果沒有設置name, 默認為Globals.ERROR_KEY. message屬性的默認值為false.