Bitter Java中文版

定　價：￥35.00

作　者：	（美）塔特著，蘇金國等譯；蘇金國譯
出版社：	機械工業(yè)出版社
叢編項：
標(biāo)　簽：	Java

購買這本書可以去

ISBN：	9787111183150	出版時間：	2006-02-01	包裝：	膠版紙
開本：	小16開	頁數(shù)：	240	字?jǐn)?shù)：

內(nèi)容簡介

　　本書系統(tǒng)地介紹了常見的服務(wù)器Java編程錯誤，以及這些錯誤產(chǎn)生的原因和解決方案。書中涵蓋了基本Java和J2EE概念的反模式，如servlet、JSP、EJB、企業(yè)連接模型和可擴展性等，通過代碼示例展示了Java編程中常見的陷阱，還提供了重構(gòu)代碼，并解釋了為什么新方案是安全的。本書適合中級水平的Java程序員、分析員或架構(gòu)師閱讀，通過研究書中介紹的反模式，可以吸收別人的經(jīng)驗教訓(xùn)，在工作中少走彎路。[前言]到了夏天，得克薩斯河水就幾近干涸。為了尋找急流，漂流者不得不跟著暴風(fēng)雨的腳步走。那是1996年夏天的一天，我和一個同伴晚上8點離開奧斯汀，沖入狂暴的風(fēng)雨中，一直來到阿肯色州的Cossatot河。等我們到了那里，壞天氣好像跟我們開了個殘酷的玩笑，居然繞過這條河徑直走了。我們筋疲力盡，失望之極，只好在河岸上扎營休息。那天晚上我們根本沒有聽到一絲雨聲。到了早上，我還是垂頭喪氣，頭昏眼花地走出帳篷，然后幾乎跌倒……在河里。Cossatot河素來就有漲水極快的壞名聲，僅僅因為上游10英里處下了2個小時的雨，水位就突漲了6英尺?，F(xiàn)在我們倒是可以漂流了，但是水位又太高。我們決定等第二天早上再來對付難度大的這一段，先到相對容易一些的上游漂流。原來水流遲緩的1級水域現(xiàn)在已經(jīng)變成了洶涌的3級急流。指南上說這一段要漂流“4個小時”，但我們只花了20分鐘就飛馳而下。“中間”河段更糟糕：湍急的河水已經(jīng)達(dá)到4級，猛烈地咆哮著。經(jīng)過仔細(xì)偵察，我們輪流在河岸上執(zhí)守，一個人在河水中漂流時，要系著安全帶，由另一個人在岸上監(jiān)視情況。然后我們把皮劃艇放在營地，徒步走下去，看看下面的河段情況怎么樣。讓我們驚訝的是，居然有幾十個當(dāng)?shù)厝嗽诤影杜苑胖梢危窨达L(fēng)景一樣看著河面。以往他們看到的只是4級瀑布，如今這條河已經(jīng)完全被可怕的大漩渦所籠罩。此前，我們很少看到當(dāng)?shù)厝?，他們在這里只是看有沒有人出風(fēng)頭，有沒有驚險的事情發(fā)生。這種景象讓我們目瞪口呆，所以我和同伴也各自坐在一塊大石頭上開始看熱鬧。追溯到2000年，盡管當(dāng)時我的職位已經(jīng)不低，而且待遇優(yōu)厚，但我還是離開了IBM，去加入一家名叫allmystuff的創(chuàng)業(yè)型（startup）公司。當(dāng)時經(jīng)濟已經(jīng)開始衰退，但是在奧斯汀其他創(chuàng)業(yè)型公司紛紛垮臺之際，這家公司卻剛剛拿到了贊助。這家公司的企業(yè)運作并不取決于廣告收入，所以盡管廣告收入日薄，似乎也影響不大，另外allmystuff里集結(jié)了許多精兵良將。我加入公司之時，它的銀行資金有一千萬美元，不僅有固定客戶，而且擁有著高新技術(shù)，這一切都預(yù)示著它很可能成為炙手可熱的成功企業(yè)。我見過許多朋友都離開IBM大旗，轉(zhuǎn)而投奔其他公司，雖然新公司的待遇不能比，也沒有安全感，但是很有冒險性。我想反正在必要時還可以回去，所以面對著即將到來的黑暗，我迎頭沖入到這場風(fēng)暴中。在奧斯汀新聞笑談曾經(jīng)紅極一時的創(chuàng)業(yè)型公司都紛紛落馬之時，allmystuff也開始在困境中掙扎。我們?nèi)找岳^夜地工作，為很少的幾個客戶部署解決方案。盡管我們的質(zhì)量一流，有讓人自豪的業(yè)績記錄，但最后還是被衰退的經(jīng)濟所累。風(fēng)險投資者決定最好還是關(guān)門大吉，再找尋一種適應(yīng)這種經(jīng)濟衰退局勢的新概念東山再起。盡管這件事本身讓人很難受，但是在我的職業(yè)生涯中，那個時期我學(xué)到的東西卻是任何其他時候都比不上的。就像Cossatot河岸上的當(dāng)?shù)厝艘粯?，如果一個冒險故事是我們身邊發(fā)生的真事，很刺激，甚至很危險，那我們大多數(shù)人都無法抵擋它的吸引力。不論是看一個久負(fù)盛名的希臘悲劇故事，還是看像電視劇“生存者”（Survivor）這樣一些最新的流行節(jié)目，我們的獵奇思想永無止境。程序員也不例外。我們很喜歡聊最近發(fā)生的冒險事情（我們把這稱為“實境談話”（merctalk）），這有很多原因。我有許多鮮活的工作記憶就是在allmystuff的乒乓球臺邊留下的。在那里我們討論過管理哲學(xué)；討論過代碼基是不是已經(jīng)失控；另外還討論過，與日益復(fù)雜的JSP模型相比，有專門瀏覽器的XML是不是一種更簡單的方案。我們還討論過，眼看著進(jìn)度不斷推遲，圖形化設(shè)計人員能不能把他設(shè)計的用戶界面映射為越來越復(fù)雜的Java命令。正是這些討論燃起了我的熱情，促使我離開了原本安穩(wěn)的職位，做著百萬富翁的夢，投向這個待遇更低、沒有安全感的新工作。這些經(jīng)驗使我成為一個更好的程序員、管理人員和架構(gòu)師。不記得在哪個場合下，前IBM主席JohnAkers曾說過，太多的人“整天都只是喝水聊天，無所事事”。我記得聽了這話我們都很生氣，他不知道，往往在喝水（或喝酒）時或者在乒乓球臺邊聽到的東西會決定一個項目（甚至一個公司）的成敗。在這里，必須聽些程序員的故事，受些熏陶，因為這些會影響一生。我準(zhǔn)備把其中一些故事放到《BitterJava》這本書里。再回到早先，那時我還沒有加入allmystuff，正準(zhǔn)備在一個會議上演講。我報告的題目是“BitterJava”。在會議期間，我遇到了一位著名的Java程序員，JSP的創(chuàng)始人之一。他告訴我曾經(jīng)在Pamplona參加過“公牛奔跑”（runwiththebulls）活動（譯者注：這是一個很經(jīng)典的活動，人們拼命地在公牛前面奔跑，一路上公牛會踩傷、踢傷或用角刺傷很多人，但人們還是樂此不疲，認(rèn)為這是勇敢者的游戲），還被刺傷了。他還很起勁地給我解釋他在參加公牛奔跑時的策略。我對他講的不以為然。在Pamplona，早有無數(shù)的人告訴過我怎樣避免被刺傷。我還向O.J.Simpson咨詢過這方面的問題。每年都有數(shù)萬個熱衷于此的人參加，但只有十幾個被刺傷。不過，慢慢地我有了想法：如果我要參加公牛奔跑，那我就會和他討論。我想知道他是怎么計劃的，他又怎么實施他的計劃，哪里出了問題。這些信息我能用得上。后來發(fā)現(xiàn)，這個被刺傷的程序員正是allmystuff工程部的副總裁，他招募我?guī)椭⑺姆?wù)機構(gòu)。再來說我的報告，盡管講這個Pamplona故事可能會讓我失去在allmystuff工作的機會，但我還是決定用這個故事來開始我的演講。它充分體現(xiàn)了《BitterJava》中的概念。要說能幫助避免一個微妙的圈套或陷阱，一個關(guān)于失敗的故事往往抵得上10個成功的故事。這個故事牢牢地吸引住了聽眾，而且……我也得到了我的工作。像許多程序員一樣，我很喜歡極限運動。我們曾劃著小艇遭遇危險，有時甚至遇到生命危險。WilliamNeely曾經(jīng)講過漂流界很有名的一個法則：你注視一個急流的時間與它吞掉你的危險往往成正比。換句話說，如果看上去漩渦大到能吃掉你，它很可能就會吃掉你。漂流者有自己的一套辦法來描述如何沿河下行。漂流指南中會指出一條路線，還會指出路線沿線以及路線之外的一些危險地方。指南中可能說，“接下來，你會看到中間有一塊大石頭，你要向左。如果誤撞到右邊，那這個急流就會成為‘終結(jié)者’，用殘酷的方式告訴你錯了?！蔽液芮宄词鼓銢]有真正了解一條河的威力，你也很想知道哪些地方可能出問題。我想知道水下有沒有巖石，有沒有陷阱等著我。我想知道哪里可能遇到漩渦，怎么躲過瀑布底下的大石頭。我想知道，是不是有人在這條河上喪生，那是怎么回事。如果沒有足夠的了解，就算有高超的技術(shù)，我往往也會回避，甚至頂著小船沿河岸一路走下去，就是不下水。程序員（包括我）也是一樣。我要了解應(yīng)用和項目會在哪里失敗。我要知道是不是與某個接口的通信太多了，所用的技術(shù)能不能解決這個問題。我得明白一個技術(shù)可能在哪里出問題，這個技術(shù)能不能擴展。我深信，要想成功，軟件開發(fā)中總少不了失敗，而且勢必要從中學(xué)習(xí)。我還沒有看到哪個組織能系統(tǒng)地從錯誤中學(xué)習(xí)，并以正規(guī)、系統(tǒng)的方式仔細(xì)分析為什么要修改一個有問題的設(shè)計模式或過程。我曾經(jīng)看過許多代碼，但并不是所有代碼都很好。我已經(jīng)領(lǐng)會到“bitterJava”的魅力，希望你也一樣。

作者簡介

　　BrunceA.Tate在IBM和一家創(chuàng)業(yè)型公司有14年的工作經(jīng)驗，其中一半時間都在擔(dān)任Internet架構(gòu)師。他還著有另外兩本計算機書。

圖書目錄

第一部分　基礎(chǔ) 知識
第1章　Bitter傳說        2
1.1　自由降落的Java開發(fā)        2
1.1.1　生活中的反模式        4
1.2　使用設(shè)計模式強調(diào)正面        4
1.2.1　設(shè)計模式在線資源        5
1.2.2　UML為模式提供了語言        6
1.3　反模式從負(fù)面學(xué)習(xí)        6
1.3.1　一些著名的反模式        6
1.3.2　實際中的反模式        7
1.3.3　反模式資源        8
1.4　反模式的思想并不是全新的        9
1.4.1　從業(yè)界學(xué)到的教訓(xùn)        9
1.4.2　檢測工作        10
1.4.3　重構(gòu)反模式        11
1.5　為什么寫這本書        11
1.5.1　本書方法        12
1.5.2　本書工具        12
1.5.3　本書組織結(jié)構(gòu)        12
1.5.4　本書讀者對象        14
1.6　前瞻        14
第2章　狀況之苦        15
2.1　反模式滋生的土壤        15
2.1.1　分層的好處        15
2.1.2　分層也會對我們不利        17
2.2　Internet技術(shù)        18
2.2.1　Internet拓?fù)浣Y(jié)構(gòu)會影響我們的應(yīng)用        18
2.2.2　企業(yè)層可以增加安全，也會加大開銷        19
2.2.3　標(biāo)準(zhǔn)提供了Internet支持，同時增加了層        21
2.2.4　TCP和IP提供底層通信        21
2.2.5　HTTP提供應(yīng)用級傳輸        22
2.2.6　HTML和XML        22
2.2.7　小反模式：Web頁面上有太多元素        23
2.3　對象技術(shù)和反模式        25
2.3.1　封裝有助于隔離修改        25
2.3.2　繼承支持共同行為的打包        26
2.3.3　多態(tài)支持靈活的重用        26
2.3.4　小反模式：過度分層        27
2.3.5　Java的舞臺        28
2.4　Java技術(shù)解決反模式        28
2.5　瀑布的主要問題        30
2.5.1　迭代方法        31
2.5.2　小反模式：不完整的過程轉(zhuǎn)換        31
2.5.3　編程新視野：極限編程        32
2.6　狀況之苦速覽        33
2.7　本章介紹的反模式        33
第二部分　服務(wù)器端Java反模式
第3章　servlet之苦        37
3.1　孤注一擲        37
3.1.1　早期的反模式：神奇按鈕        37
3.1.2　利用模型-視圖-控制器模式構(gòu)建        38
3.1.3　未能分離模型和視圖        39
3.1.4　分出模型        40
3.2　反模式：神奇servlet        41
3.2.1　可以使用servlet作為模型嗎        41
3.2.2　落入神奇servlet陷阱        43
3.2.3　導(dǎo)致神奇servlet的原因        46
3.3　解決方案：使用命令重構(gòu)        47
3.3.1　分出模型        47
3.3.2　用命令對象包裝模型        48
3.3.3　分離模型邏輯        48
3.3.4　分離返回視圖        52
3.3.5　使用JSP建立返回視圖        54
3.4　小結(jié)        56
3.5　本章介紹的反模式        56
第4章　JSP之苦        58
4.1　還沒有結(jié)束        58
4.1.1　找出危險信號        58
4.2　反模式：整塊JSP        59
4.2.1　這個程序未能做到模型-視圖分離        60
4.2.2　解決方案：重構(gòu)為模型-視圖-控制器        61
4.3　反模式：復(fù)合JSP        62
4.3.1　該不該結(jié)合多個JSP        63
4.3.2　結(jié)合了兩個界面的例子        64
4.3.3　解決方案：分解JSP        68
4.3.4　在控制器servlet中做判定        68
4.4　小反模式：過粗和過細(xì)的命令        71
4.4.1　一組中有太多的命令        72
4.4.2　解決方案：重構(gòu)為合適的粒度        72
4.4.3　有關(guān)粒度的提示        73
4.5　小反模式：胖命令        74
4.6　反模式回顧        74
4.7　本章介紹的反模式        74
第5章　緩存管理之苦        77
5.1　我們需要緩存！        77
5.2　反模式：缺少緩存        79
5.2.1　沒有緩存的糟糕BBS        79
5.2.2　構(gòu)建ShowBoard的模型、視圖和控制器        80
5.2.3　構(gòu)建ShowThread的模型、視圖和控制器        82
5.2.4　構(gòu)建AddPost的模型、視圖和控制器        86
5.2.5　性能問題        91
5.3　解決方案：緩存        91
5.3.1　解決方案1：使用一個硬件緩存        92
5.3.2　解決方案2：緩存命令        92
5.3.3　為BBS增加緩存        93
5.3.4　對緩存命令的改進(jìn)        97
5.4　與緩存有關(guān)的小反模式        99
5.4.1　對靜態(tài)緩存的并發(fā)訪問        99
5.4.2　不斷膨脹的緩存        99
5.5　反模式：同步讀/寫瓶頸        99
5.5.1　讀者之間的沖突會降低性能        100
5.5.2　讀/寫鎖允許正確地共享訪問        101
5.6　消除無緩存反模式        102
5.7　本章介紹的反模式        103
第6章　內(nèi)存之苦        105
6.1　了解內(nèi)存泄漏和反模式        105
6.1.1　管理內(nèi)存        106
6.1.2　理解垃圾回收        106
6.1.3　引用計數(shù)        107
6.1.4　可達(dá)對象        108
6.2　C++換Java        109
6.2.1　導(dǎo)致Java內(nèi)存泄漏的情況        109
6.2.2　找出Java的內(nèi)存泄漏        109
6.3　反模式：流失監(jiān)聽者泄漏        110
6.3.1　分析一些危險的做法        111
6.3.2　解決方案1：顯式地刪除監(jiān)聽者        113
6.3.3　解決方案2：縮短錨的生命周期        114
6.3.4　解決方案3：弱化引用        114
6.3.5　引用對象可以簡化內(nèi)存管理        115
6.4　反模式：泄漏集合        115
6.4.1　由于緩存和會話狀態(tài)導(dǎo)致的問題        116
6.4.2　解決方案1：搜索常見的警告信號        116
6.4.3　解決方案2：讓增加/刪除調(diào)用匹配        117
6.4.4　解決方案3：使用軟引用完成緩存        117
6.4.5　解決方案4：使用帶弱引用的集合        118
6.4.6　解決方案5：使用finally        118
6.5　解決內(nèi)存泄漏        118
6.5.1　確信存在泄漏        118
6.5.2　確定泄漏應(yīng)當(dāng)?shù)玫叫拚?nbsp;       119
6.5.3　隔離問題        120
6.5.4　確定根源，修正問題        120
6.5.5　防止將來出現(xiàn)同樣的問題        121
6.6　小反模式：小肥豬        121
6.6.1　串管理        122
6.6.2　集合        122
6.6.3　繼承鏈        123
6.7　小結(jié)        123
6.8　本章介紹的反模式        123
第7章　連接和耦合之苦        125
7.1　建立連接        125
7.2　反模式：連接抖動        125
7.2.1　對每個訪問都創(chuàng)建和終止連接        126
7.2.2　解決方案：利用池來重用連接        127
7.2.3　重構(gòu)BBS例子，增加入池連接        129
7.2.4　使用getPooledConnection        130
7.2.5　使用J2EE連接器體系結(jié)構(gòu)        131
7.3　反模式：分離清潔器        132
7.3.1　異?？赡軐?dǎo)致分離清潔器        133
7.3.2　解決方案：在finally中讓連接與清理配對        134
7.4　反模式：捆綁的連接        135
7.4.1　通信緩沖區(qū)        136
7.4.2　過早綁定        138
7.4.3　解決方案1：利用XML消息解耦合        138
7.4.4　解決方案2：利用Web服務(wù)延遲綁定        139
7.5　關(guān)于XML誤用的小反模式        140
7.5.1　XML金榔頭        140
7.5.2　XML轉(zhuǎn)換之苦        141
7.6　小反模式：嚴(yán)格XML        142
7.6.1　命名沖突        142
7.6.2　嚴(yán)格構(gòu)造        144
7.6.3　限制性的可變內(nèi)容容器        145
7.6.4　XML版本問題        147
7.7　小結(jié)：苦連接變甜        148
7.8　本章介紹的反模式        148
第8章　bean之苦        151
8.1　Enterprise JavaBeans簡要回顧        151
8.1.1　基于組件的分布式體系結(jié)構(gòu)        152
8.1.2　EJB的類型        152
8.2　利用EJB實現(xiàn)的糟糕BBS        153
8.2.1　EJB應(yīng)用中的元素        154
8.2.2　構(gòu)建遠(yuǎn)程接口        155
8.2.3　創(chuàng)建home接口        156
8.2.4　實現(xiàn)bean類        158
8.2.5　定義主鍵        162
8.2.6　創(chuàng)建部署描述文件        163
8.2.7　使用模型        165
8.3　反模式：往返通信        165
8.3.1　計算分布式部署的開銷        166
8.3.2　會話太多的接口        167
8.3.3　解決方案：利用外觀組合往返通信        168
8.3.4　往返通信的根源        169
8.3.5　利用外觀重構(gòu)BBS        169
8.4　反模式：張冠李戴        175
8.4.1　小反模式：bean托管連接        175
8.4.2　解決方案：視圖、映射器、bean托管連接        176
8.4.3　小反模式：實體bean只是完成一些輕量級的功能        176
8.4.4　小反模式：實體bean僅用于讀        177
8.4.5　小反模式：實體bean僅用于寫而不讀        177
8.4.6　麻煩的可滾動列表        177
8.4.7　總解決方案：選擇合適的bean完成合適的任務(wù)        178
8.5　小反模式：一切都是EJB        178
8.6　EJB和緩存        179
8.6.1　利用外觀實現(xiàn)緩存        179
8.7　消除苦bean        180
8.8　本章介紹的反模式        180
第三部分　全  景  圖
第9章　衛(wèi)生之苦        184
9.1　為什么要研究編程衛(wèi)生        184
9.1.1　極限編程需要好的編程衛(wèi)生        185
9.1.2　編碼標(biāo)準(zhǔn)可以避免反模式        185
9.2　小反模式：不可達(dá)的代碼        186
9.2.1　名字匹配        186
9.2.2　命名標(biāo)準(zhǔn)        187
9.2.3　大括號和縮進(jìn)        190
9.2.4　注釋        191
9.2.5　制表符和空格        194
9.2.6　編輯器        194
9.3　小反模式：組織和可見性        195
9.4　小反模式：結(jié)構(gòu)        198
9.4.1　基本面向?qū)ο罄碚?nbsp;       198
9.4.2　低級設(shè)計因素        198
9.4.3　異常        200
9.5　小反模式：泄漏和性能        200
9.6　測試的約定        201
9.7　建立一個好的風(fēng)格指南        202
9.7.1　是買、是借還是偷？        202
9.7.2　Contextual公司的一個示例風(fēng)格指南        203
9.8　編碼標(biāo)準(zhǔn)小結(jié)        205
第10章　可擴展性之苦        208
10.1　保證性能的好拓?fù)?nbsp;       208
10.1.1　同構(gòu)組中的硬件分層        210
10.1.2　其他拓?fù)渥兎N        211
10.2　反模式：事后再考慮性能        212
10.2.1　開發(fā)時不做性能規(guī)劃        213
10.2.2　一些真實世界的例子        213
10.2.3　解決方案：做性能規(guī)劃！        214
10.3　反模式：往返通信        216
10.3.1　解決方案：緩存和外觀        216
10.4　反模式：不好的負(fù)載管理        217
10.4.1　解決方案：工作負(fù)載管理        219
10.4.2　真正的負(fù)載平衡        220
10.5　反模式：混亂的會話管理        221
10.5.1　解決方案1：利用會話親緣性分派        221
10.5.2　解決方案2：使用一個分布式狀態(tài)管理服務(wù)        221
10.5.3　使用定制會話bean解決方案        222
10.5.4　使用定制實體bean解決方案        222
10.6　反模式：抖動調(diào)優(yōu)        222
10.6.1　解決方案：使用合理的性能改進(jìn)方法        223
10.7　馴服性能野獸        224
10.8　本章介紹的反模式        224
第11章　圓滿的告別        227
11.1　反模式可以在很多層次上提供幫助        227
11.1.1　反模式促進(jìn)職業(yè)發(fā)展        228
11.1.2　了解反模式可以改善程序        228
11.1.3　了解反模式可以使你成為一個更好的程序員        228
11.2　在過程中集成反模式        229
11.3　更上一層樓        230
附錄A　反模式參照表        232
參考文獻(xiàn)        238