編寫(xiě)高質(zhì)量代碼（改善Java程序的151個(gè)建議）

\h編寫(xiě)高質(zhì)量代碼改善Java程序的151個(gè)建議目錄\h第1章Java開(kāi)發(fā)中通用的方法和準(zhǔn)則\h建議1：不要在常量和變量中出現(xiàn)易混淆的字母\h建議2：莫讓常量蛻變成變量\h建議3：三元操作符的類(lèi)型務(wù)必一致\h建議4：避免帶有變長(zhǎng)參數(shù)的方法重載\h建議5：別讓null值和空值威脅到變長(zhǎng)方法\h建議6：覆寫(xiě)變長(zhǎng)方法也循規(guī)蹈矩\h建議7：警惕自增的陷阱\h建議8：不要讓舊語(yǔ)法困擾你\h建議9：少用靜態(tài)導(dǎo)入\h建議10：不要在本類(lèi)中覆蓋靜態(tài)導(dǎo)入的變量和方法\h建議11：養(yǎng)成良好習(xí)慣，顯式聲明UID\h建議12：避免用序列化類(lèi)在構(gòu)造函數(shù)中為不變量賦值\h建議13：避免為final變量復(fù)雜賦值\h建議14：使用序列化類(lèi)的私有方法巧妙解決部分屬性持久化問(wèn)題\h建議15：break萬(wàn)萬(wàn)不可忘\h建議16：易變業(yè)務(wù)使用腳本語(yǔ)言編寫(xiě)\h建議17：慎用動(dòng)態(tài)編譯\h建議18：避免instanceof非預(yù)期結(jié)果\h建議19：斷言絕對(duì)不是雞肋\(yùn)h建議20：不要只替換一個(gè)類(lèi)\h第2章基本類(lèi)型\h建議21：用偶判斷，不用奇判斷\h建議22：用整數(shù)類(lèi)型處理貨幣\h建議23：不要讓類(lèi)型默默轉(zhuǎn)換\h建議24：邊界，邊界，還是邊界\h建議25：不要讓四舍五入虧了一方\h建議26：提防包裝類(lèi)型的null值\h建議27：謹(jǐn)慎包裝類(lèi)型的大小比較\h建議28：優(yōu)先使用整型池\h建議29：優(yōu)先選擇基本類(lèi)型\h建議30：不要隨便設(shè)置隨機(jī)種子\h第3章類(lèi)、對(duì)象及方法\h建議31：在接口中不要存在實(shí)現(xiàn)代碼\h建議32：靜態(tài)變量一定要先聲明后賦值\h建議33：不要覆寫(xiě)靜態(tài)方法\h建議34：構(gòu)造函數(shù)盡量簡(jiǎn)化\h建議35：避免在構(gòu)造函數(shù)中初始化其他類(lèi)\h建議36：使用構(gòu)造代碼塊精煉程序\h建議37：構(gòu)造代碼塊會(huì)想你所想\h建議38：使用靜態(tài)內(nèi)部類(lèi)提高封裝性\h建議39：使用匿名類(lèi)的構(gòu)造函數(shù)\h建議40：匿名類(lèi)的構(gòu)造函數(shù)很特殊\h建議41：讓多重繼承成為現(xiàn)實(shí)\h建議42：讓工具類(lèi)不可實(shí)例化\h建議43：避免對(duì)象的淺拷貝\h建議44：推薦使用序列化實(shí)現(xiàn)對(duì)象的拷貝\h建議45：覆寫(xiě)equals方法時(shí)不要識(shí)別不出自己\h建議46：equals應(yīng)該考慮null值情景\h建議47：在equals中使用getClass進(jìn)行類(lèi)型判斷\h建議48：覆寫(xiě)equals方法必須覆寫(xiě)hashCode方法\h建議49：推薦覆寫(xiě)toString方法\h建議50：使用package-info類(lèi)為包服務(wù)\h建議51：不要主動(dòng)進(jìn)行垃圾回收\(chéng)h第4章字符串\h建議52：推薦使用String直接量賦值\h建議53：注意方法中傳遞的參數(shù)要求\h建議54：正確使用String、StringBuffer、StringBuilder\h建議55：注意字符串的位置\h建議56：自由選擇字符串拼接方法\h建議57：推薦在復(fù)雜字符串操作中使用正則表達(dá)式\h建議58：強(qiáng)烈建議使用UTF編碼\h建議59：對(duì)字符串排序持一種寬容的心態(tài)\h第5章數(shù)組和集合\h建議60：性能考慮，數(shù)組是首選\h建議61：若有必要，使用變長(zhǎng)數(shù)組\h建議62：警惕數(shù)組的淺拷貝\h建議63：在明確的場(chǎng)景下，為集合指定初始容量\h建議64：多種最值算法，適時(shí)選擇\h建議65：避開(kāi)基本類(lèi)型數(shù)組轉(zhuǎn)換列表陷阱\h建議66：asList方法產(chǎn)生的List對(duì)象不可更改\h建議67：不同的列表選擇不同的遍歷方法\h建議68：頻繁插入和刪除時(shí)使用LinkedList\h建議69：列表相等只需關(guān)心元素?cái)?shù)據(jù)\h建議70：子列表只是原列表的一個(gè)視圖\h建議71：推薦使用subList處理局部列表\h建議72：生成子列表后不要再操作原列表\h建議73：使用Comparator進(jìn)行排序\h建議74：不推薦使用binarySearch對(duì)列表進(jìn)行檢索\h建議75：集合中的元素必須做到compareTo和equals同步\h建議76：集合運(yùn)算時(shí)使用更優(yōu)雅的方式\h建議77：使用shuffle打亂列表\h建議78：減少HashMap中元素的數(shù)量\h建議79：集合中的哈希碼不要重復(fù)\h建議80：多線程使用Vector或HashTable\h建議81：非穩(wěn)定排序推薦使用List\h建議82：由點(diǎn)及面，一葉知秋——集合大家族\h第6章枚舉和注解\h建議83：推薦使用枚舉定義常量\h建議84：使用構(gòu)造函數(shù)協(xié)助描述枚舉項(xiàng)\h建議85：小心switch帶來(lái)的空值異常\h建議86：在switch的default代碼塊中增加AssertionError錯(cuò)誤\h建議87：使用valueOf前必須進(jìn)行校驗(yàn)\h建議88：用枚舉實(shí)現(xiàn)工廠方法模式更簡(jiǎn)潔\h建議89：枚舉項(xiàng)的數(shù)量限制在64個(gè)以內(nèi)\h建議90：小心注解繼承\(zhòng)h建議91：枚舉和注解結(jié)合使用威力更大\h建議92：注意@Override不同版本的區(qū)別\h第7章泛型和反射\h建議93：Java的泛型是類(lèi)型擦除的\h建議94：不能初始化泛型參數(shù)和數(shù)組\h建議95：強(qiáng)制聲明泛型的實(shí)際類(lèi)型\h建議96：不同的場(chǎng)景使用不同的泛型通配符\h建議97：警惕泛型是不能協(xié)變和逆變的\h建議98：建議采用的順序是List＜T＞、List＜?＞、List＜Object＞\h建議99：嚴(yán)格限定泛型類(lèi)型采用多重界限\h建議100：數(shù)組的真實(shí)類(lèi)型必須是泛型類(lèi)型的子類(lèi)型\h建議101：注意Class類(lèi)的特殊性\h建議102：適時(shí)選擇getDeclared×××和get×××\h建議103：反射訪問(wèn)屬性或方法時(shí)將Accessible設(shè)置為true\h建議104：使用forName動(dòng)態(tài)加載類(lèi)文件\h建議105：動(dòng)態(tài)加載不適合數(shù)組\h建議106：動(dòng)態(tài)代理可以使代理模式更加靈活\h建議107：使用反射增加裝飾模式的普適性\h建議108：反射讓模板方法模式更強(qiáng)大\h建議109：不需要太多關(guān)注反射效率\h第8章異常\h建議110：提倡異常封裝\h建議111：采用異常鏈傳遞異常\h建議112：受檢異常盡可能轉(zhuǎn)化為非受檢異常\h建議113：不要在finally塊中處理返回值\h建議114：不要在構(gòu)造函數(shù)中拋出異常\h建議115：使用Throwable獲得棧信息\h建議116：異常只為異常服務(wù)\h建議117：多使用異常，把性能問(wèn)題放一邊\h第9章多線程和并發(fā)\h建議118：不推薦覆寫(xiě)start方法\h建議119：?jiǎn)?dòng)線程前stop方法是不可靠的\h建議120：不使用stop方法停止線程\h建議121：線程優(yōu)先級(jí)只使用三個(gè)等級(jí)\h建議122：使用線程異常處理器提升系統(tǒng)可靠性\h建議123：volatile不能保證數(shù)據(jù)同步\h建議124：異步運(yùn)算考慮使用Callable接口\h建議125：優(yōu)先選擇線程池\h建議126：適時(shí)選擇不同的線程池來(lái)實(shí)現(xiàn)\h建議127：Lock與synchronized是不一樣的\h建議128：預(yù)防線程死鎖\h建議129：適當(dāng)設(shè)置阻塞隊(duì)列長(zhǎng)度\h建議130：使用CountDownLatch協(xié)調(diào)子線程\h建議131：CyclicBarrier讓多線程齊步走\(yùn)h第10章性能和效率\h建議132：提升Java性能的基本方法\h建議133：若非必要，不要克隆對(duì)象\h建議134：推薦使用“望聞問(wèn)切”的方式診斷性能\h建議135：必須定義性能衡量標(biāo)準(zhǔn)\h建議136：槍打出頭鳥(niǎo)——解決首要系統(tǒng)性能問(wèn)題\h建議137：調(diào)整JVM參數(shù)以提升性能\h建議138：性能是個(gè)大“咕咚”\h第11章開(kāi)源世界\h建議139：大膽采用開(kāi)源工具\(yùn)h建議140：推薦使用Guava擴(kuò)展工具包\h建議141：Apache擴(kuò)展包\h建議142：推薦使用Joda日期時(shí)間擴(kuò)展包\h建議143：可以選擇多種Collections擴(kuò)展\h第12章思想為源\h建議144：提倡良好的代碼風(fēng)格\h建議145：不要完全依靠單元測(cè)試來(lái)發(fā)現(xiàn)問(wèn)題\h建議146：讓注釋正確、清晰、簡(jiǎn)潔\h建議147：讓接口的職責(zé)保持單一\h建議148：增強(qiáng)類(lèi)的可替換性\h建議149：依賴抽象而不是實(shí)現(xiàn)\h建議150：拋棄7條不良的編碼習(xí)慣\h建議151：以技術(shù)員自律而不是工人第1章Java開(kāi)發(fā)中通用的方法和準(zhǔn)則Thereasonablemanadaptshimselftotheworld；theunreasonableonepersistsintryingtoadapttheworldtohimself.明白事理的人使自己適應(yīng)世界；不明事理的人想讓世界適應(yīng)自己?！挷{Java的世界豐富又多彩，但同時(shí)也布滿了荊棘陷阱，大家一不小心就可能跌入黑暗深淵，只有在了解了其通行規(guī)則后才能使自己在技術(shù)的海洋里遨游飛翔，恣意馳騁。“千里之行始于足下”，本章主要講述與Java語(yǔ)言基礎(chǔ)有關(guān)的問(wèn)題及建議的解決方案，例如常量和變量的注意事項(xiàng)、如何更安全地序列化、斷言到底該如何使用等。建議1：不要在常量和變量中出現(xiàn)易混淆的字母包名全小寫(xiě)，類(lèi)名首字母全大寫(xiě)，常量全部大寫(xiě)并用下劃線分隔，變量采用駝峰命名法（CamelCase）命名等，這些都是最基本的Java編碼規(guī)范，是每個(gè)Javaer都應(yīng)熟知的規(guī)則，但是在變量的聲明中要注意不要引入容易混淆的字母。嘗試閱讀如下代碼，思考一下打印出的i等于多少：publicclassClient{publicstaticvoidmain（String[]args）{longi=1l；System.out.println（"i的兩倍是："+（i+i））；}}肯定有人會(huì)說(shuō)：這么簡(jiǎn)單的例子還能出錯(cuò)？運(yùn)行結(jié)果肯定是22！實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)，將其拷貝到Eclipse中，然后Run一下看看，或許你會(huì)很奇怪，結(jié)果是2，而不是22，難道是Eclipse的顯示有問(wèn)題，少了個(gè)“2”？因?yàn)橘x給變量i的數(shù)字就是“1”，只是后面加了長(zhǎng)整型變量的標(biāo)示字母"l"而已。別說(shuō)是我挖坑讓你跳，如果有類(lèi)似程序出現(xiàn)在項(xiàng)目中，當(dāng)你試圖通過(guò)閱讀代碼來(lái)理解作者的思想時(shí)，此情此景就有可能會(huì)出現(xiàn)。所以，為了讓您的程序更容易理解，字母"l"（還包括大寫(xiě)字母"O"）盡量不要和數(shù)字混用，以免使閱讀者的理解與程序意圖產(chǎn)生偏差。如果字母和數(shù)字必須混合使用，字母"l"務(wù)必大寫(xiě)，字母"O"則增加注釋。注意字母"l"作為長(zhǎng)整型標(biāo)志時(shí)務(wù)必大寫(xiě)。建議2：莫讓常量蛻變成變量常量蛻變成變量？你胡扯吧，加了final和static的常量怎么可能會(huì)變呢？不可能二次賦值的呀。真的不可能嗎？看我們神奇的魔術(shù)，代碼如下：publicclassClient{publicstaticvoidmain（String[]args）{System.out.println（"常量會(huì)變哦："+Const.RAND_CONST）；}}/*接口常量*/interfaceConst{//這還是常量嗎？publicstaticfnalintRAND_CONST=newRandom（）.nextInt（）；}RAND_CONST是常量嗎？它的值會(huì)變嗎？絕對(duì)會(huì)變！這種常量的定義方式是極不可取的，常量就是常量，在編譯期就必須確定其值，不應(yīng)該在運(yùn)行期更改，否則程序的可讀性會(huì)非常差，甚至連作者自己都不能確定在運(yùn)行期發(fā)生了何種神奇的事情。甭想著使用常量會(huì)變的這個(gè)功能來(lái)實(shí)現(xiàn)序列號(hào)算法、隨機(jī)種子生成，除非這真的是項(xiàng)目中的唯一方案，否則就放棄吧，常量還是當(dāng)常量使用。注意務(wù)必讓常量的值在運(yùn)行期保持不變。建議3：三元操作符的類(lèi)型務(wù)必一致三元操作符是if-else的簡(jiǎn)化寫(xiě)法，在項(xiàng)目中使用它的地方很多，也非常好用，但是好用又簡(jiǎn)單的東西并不表示就可以隨便用，我們來(lái)看看下面這段代碼：publicclassClient{publicstaticvoidmain（String[]args）{inti=80；Strings=String.valueOf（i＜100?90:100）；Strings1=String.valueOf（i＜100?90:100.0）；System.out.println（"兩者是否相等："+s.equals（s1））；}}分析一下這段程序：i是80，那它當(dāng)然小于100，兩者的返回值肯定都是90，再轉(zhuǎn)成String類(lèi)型，其值也絕對(duì)相等，毋庸置疑的。恩，分析得有點(diǎn)道理，但是變量s中三元操作符的第二個(gè)操作數(shù)是100，而s1的第二個(gè)操作數(shù)是100.0，難道沒(méi)有影響嗎？不可能有影響吧，三元操作符的條件都為真了，只返回第一個(gè)值嘛，與第二個(gè)值有一毛錢(qián)的關(guān)系嗎？貌似有道理。果真如此嗎？我們通過(guò)結(jié)果來(lái)驗(yàn)證一下，運(yùn)行結(jié)果是：“兩者是否相等：false”，什么？不相等，Why？問(wèn)題就出在了100和100.0這兩個(gè)數(shù)字上，在變量s中，三元操作符中的第一個(gè)操作數(shù)（90）和第二個(gè)操作數(shù)（100）都是int類(lèi)型，類(lèi)型相同，返回的結(jié)果也就是int類(lèi)型的90，而變量s1的情況就有點(diǎn)不同了，第一個(gè)操作數(shù)是90（int類(lèi)型），第二個(gè)操作數(shù)卻是100.0，而這是個(gè)浮點(diǎn)數(shù)，也就是說(shuō)兩個(gè)操作數(shù)的類(lèi)型不一致，可三元操作符必須要返回一個(gè)數(shù)據(jù)，而且類(lèi)型要確定，不可能條件為真時(shí)返回int類(lèi)型，條件為假時(shí)返回float類(lèi)型，編譯器是不允許如此的，所以它就會(huì)進(jìn)行類(lèi)型轉(zhuǎn)換了，int型轉(zhuǎn)換為浮點(diǎn)數(shù)90.0，也就是說(shuō)三元操作符的返回值是浮點(diǎn)數(shù)90.0，那這當(dāng)然與整型的90不相等了。這里可能有讀者疑惑了：為什么是整型轉(zhuǎn)為浮點(diǎn)，而不是浮點(diǎn)轉(zhuǎn)為整型呢？這就涉及三元操作符類(lèi)型的轉(zhuǎn)換規(guī)則：若兩個(gè)操作數(shù)不可轉(zhuǎn)換，則不做轉(zhuǎn)換，返回值為Object類(lèi)型。若兩個(gè)操作數(shù)是明確類(lèi)型的表達(dá)式（比如變量），則按照正常的二進(jìn)制數(shù)字來(lái)轉(zhuǎn)換，int類(lèi)型轉(zhuǎn)換為long類(lèi)型，long類(lèi)型轉(zhuǎn)換為float類(lèi)型等。若兩個(gè)操作數(shù)中有一個(gè)是數(shù)字S，另外一個(gè)是表達(dá)式，且其類(lèi)型標(biāo)示為T(mén)，那么，若數(shù)字S在T的范圍內(nèi)，則轉(zhuǎn)換為T(mén)類(lèi)型；若S超出了T類(lèi)型的范圍，則T轉(zhuǎn)換為S類(lèi)型（可以參考“建議22”，會(huì)對(duì)該問(wèn)題進(jìn)行展開(kāi)描述）。若兩個(gè)操作數(shù)都是直接量數(shù)字（Literal）\h[1]，則返回值類(lèi)型為范圍較大者。知道是什么原因了，相應(yīng)的解決辦法也就有了：保證三元操作符中的兩個(gè)操作數(shù)類(lèi)型一致，即可減少可能錯(cuò)誤的發(fā)生。\h[1]"Literal"也譯作“字面量”。建議4：避免帶有變長(zhǎng)參數(shù)的方法重載在項(xiàng)目和系統(tǒng)的開(kāi)發(fā)中，為了提高方法的靈活度和可復(fù)用性，我們經(jīng)常要傳遞不確定數(shù)量的參數(shù)到方法中，在Java5之前常用的設(shè)計(jì)技巧就是把形參定義成Collection類(lèi)型或其子類(lèi)類(lèi)型，或者是數(shù)組類(lèi)型，這種方法的缺點(diǎn)就是需要對(duì)空參數(shù)進(jìn)行判斷和篩選，比如實(shí)參為null值和長(zhǎng)度為0的Collection或數(shù)組。而Java5引入變長(zhǎng)參數(shù)（varags）就是為了更好地提高方法的復(fù)用性，讓方法的調(diào)用者可以“隨心所欲”地傳遞實(shí)參數(shù)量，當(dāng)然變長(zhǎng)參數(shù)也是要遵循一定規(guī)則的，比如變長(zhǎng)參數(shù)必須是方法中的最后一個(gè)參數(shù)；一個(gè)方法不能定義多個(gè)變長(zhǎng)參數(shù)等，這些基本規(guī)則需要牢記，但是即使記住了這些規(guī)則，仍然有可能出現(xiàn)錯(cuò)誤，我們來(lái)看如下代碼：publicclassClient{//簡(jiǎn)單折扣計(jì)算publicvoidcalPrice（intprice,intdiscount）{floatknockdownPrice=price*discount/100.0F；System.out.println（"簡(jiǎn)單折扣后的價(jià)格是："+formateCurrency（knockdownPrice））；}//復(fù)雜多折扣計(jì)算publicvoidcalPrice（intprice,int……discounts）{floatknockdownPrice=price；for（intdiscount：discounts）{knockdownPrice=knockdownPrice*discount/100；}System.out.println（"復(fù)雜折扣后的價(jià)格是："+formateCurrency（knockdownPrice））；}//格式化成本的貨幣形式privateStringformateCurrency（floatprice）{returnNumberFormat.getCurrencyInstance（）.format（price/100）；}publicstaticvoidmain（String[]args）{Clientclient=newClient（）；//499元的貨物，打75折client.calPrice（49900，75）；}}這是一個(gè)計(jì)算商品價(jià)格折扣的模擬類(lèi)，帶有兩個(gè)參數(shù)的calPrice方法（該方法的業(yè)務(wù)邏輯是：提供商品的原價(jià)和折扣率，即可獲得商品的折扣價(jià)）是一個(gè)簡(jiǎn)單的折扣計(jì)算方法，該方法在實(shí)際項(xiàng)目中經(jīng)常會(huì)用到，這是單一的打折方法。而帶有變長(zhǎng)參數(shù)的calPrice方法則是較復(fù)雜的折扣計(jì)算方式，多種折扣的疊加運(yùn)算（模擬類(lèi)是一種比較簡(jiǎn)單的實(shí)現(xiàn)）在實(shí)際生活中也是經(jīng)常見(jiàn)到的，比如在大甩賣(mài)期間對(duì)VIP會(huì)員再度進(jìn)行打折；或者當(dāng)天是你的生日，再給你打個(gè)9折，也就是俗話說(shuō)的“折上折”。業(yè)務(wù)邏輯清楚了，我們來(lái)仔細(xì)看看這兩個(gè)方法，它們是重載嗎？當(dāng)然是了，重載的定義是“方法名相同，參數(shù)類(lèi)型或數(shù)量不同”，很明顯這兩個(gè)方法是重載。但是再仔細(xì)瞧瞧，這個(gè)重載有點(diǎn)特殊：calPrice（intprice,int...discounts）的參數(shù)范疇覆蓋了calPrice（intprice,intdiscount）的參數(shù)范疇。那問(wèn)題就出來(lái)了：對(duì)于calPrice（49900,75）這樣的計(jì)算，到底該調(diào)用哪個(gè)方法來(lái)處理呢？我們知道Java編譯器是很聰明的，它在編譯時(shí)會(huì)根據(jù)方法簽名（MethodSignature）來(lái)確定調(diào)用哪個(gè)方法，比如calPrice（499900,75,95）這個(gè)調(diào)用，很明顯75和95會(huì)被轉(zhuǎn)成一個(gè)包含兩個(gè)元素的數(shù)組，并傳遞到calPrice（intprice,in..discounts）中，因?yàn)橹挥羞@一個(gè)方法簽名符合該實(shí)參類(lèi)型，這很容易理解。但是我們現(xiàn)在面對(duì)的是calPrice（49900,75）調(diào)用，這個(gè)“75”既可以被編譯成int類(lèi)型的“75”，也可以被編譯成int數(shù)組“{75}”，即只包含一個(gè)元素的數(shù)組。那到底該調(diào)用哪一個(gè)方法呢？我們先運(yùn)行一下看看結(jié)果，運(yùn)行結(jié)果是：簡(jiǎn)單折扣后的價(jià)格是：￥374.25?？磥?lái)是調(diào)用了第一個(gè)方法，為什么會(huì)調(diào)用第一個(gè)方法，而不是第二個(gè)變長(zhǎng)參數(shù)方法呢？因?yàn)镴ava在編譯時(shí)，首先會(huì)根據(jù)實(shí)參的數(shù)量和類(lèi)型（這里是2個(gè)實(shí)參，都為int類(lèi)型，注意沒(méi)有轉(zhuǎn)成int數(shù)組）來(lái)進(jìn)行處理，也就是查找到calPrice（intprice,intdiscount）方法，而且確認(rèn)它是否符合方法簽名條件?，F(xiàn)在的問(wèn)題是編譯器為什么會(huì)首先根據(jù)2個(gè)int類(lèi)型的實(shí)參而不是1個(gè)int類(lèi)型、1個(gè)int數(shù)組類(lèi)型的實(shí)參來(lái)查找方法呢？這是個(gè)好問(wèn)題，也非常好回答：因?yàn)閕nt是一個(gè)原生數(shù)據(jù)類(lèi)型，而數(shù)組本身是一個(gè)對(duì)象，編譯器想要“偷懶”，于是它會(huì)從最簡(jiǎn)單的開(kāi)始“猜想”，只要符合編譯條件的即可通過(guò)，于是就出現(xiàn)了此問(wèn)題。問(wèn)題是闡述清楚了，為了讓我們的程序能被“人類(lèi)”看懂，還是慎重考慮變長(zhǎng)參數(shù)的方法重載吧，否則讓人傷腦筋不說(shuō)，說(shuō)不定哪天就陷入這類(lèi)小陷阱里了。建議5：別讓null值和空值威脅到變長(zhǎng)方法上一建議講解了變長(zhǎng)參數(shù)的重載問(wèn)題，本建議還會(huì)繼續(xù)討論變長(zhǎng)參數(shù)的重載問(wèn)題。上一建議的例子是變長(zhǎng)參數(shù)的范圍覆蓋了非變長(zhǎng)參數(shù)的范圍，這次我們從兩個(gè)都是變長(zhǎng)參數(shù)的方法說(shuō)起，代碼如下：publicclassClient{publicvoidmethodA（Stringstr,Integer……is）{}publicvoidmethodA（Stringstr,String……strs）{}publicstaticvoidmain（String[]args）{Clientclient=newClient（）；client.methodA（"China"，0）；client.methodA（"China"，"People"）；client.methodA（"China"）；client.methodA（"China"，null）；}}兩個(gè)methodA都進(jìn)行了重載，現(xiàn)在的問(wèn)題是：上面的代碼編譯通不過(guò)，問(wèn)題出在什么地方？看似很簡(jiǎn)單哦。有兩處編譯通不過(guò)：client.methodA（"China"）和client.methodA（"China"，null），估計(jì)你已經(jīng)猜到了，兩處的提示是相同的：方法模糊不清，編譯器不知道調(diào)用哪一個(gè)方法，但這兩處代碼反映的代碼味道可是不同的。對(duì)于methodA（"China"）方法，根據(jù)實(shí)參"China"（String類(lèi)型），兩個(gè)方法都符合形參格式，編譯器不知道該調(diào)用哪個(gè)方法，于是報(bào)錯(cuò)。我們來(lái)思考這個(gè)問(wèn)題：Client類(lèi)是一個(gè)復(fù)雜的商業(yè)邏輯，提供了兩個(gè)重載方法，從其他模塊調(diào)用（系統(tǒng)內(nèi)本地調(diào)用或系統(tǒng)外遠(yuǎn)程調(diào)用）時(shí)，調(diào)用者根據(jù)變長(zhǎng)參數(shù)的規(guī)范調(diào)用，傳入變長(zhǎng)參數(shù)的實(shí)參數(shù)量可以是N個(gè)（N＞=0），那當(dāng)然可以寫(xiě)成client.methodA（"china"）方法??！完全符合規(guī)范，但是這卻讓編譯器和調(diào)用者都很郁悶，程序符合規(guī)則卻不能運(yùn)行，如此問(wèn)題，誰(shuí)之責(zé)任呢？是Client類(lèi)的設(shè)計(jì)者，他違反了KISS原則（KeepItSimple,Stupid，即懶人原則），按照此規(guī)則設(shè)計(jì)的方法應(yīng)該很容易調(diào)用，可是現(xiàn)在在遵循規(guī)范的情況下，程序竟然出錯(cuò)了，這對(duì)設(shè)計(jì)者和開(kāi)發(fā)者而言都是應(yīng)該嚴(yán)禁出現(xiàn)的。對(duì)于client.methodA（"china"，null）方法，直接量null是沒(méi)有類(lèi)型的，雖然兩個(gè)methodA方法都符合調(diào)用請(qǐng)求，但不知道調(diào)用哪一個(gè)，于是報(bào)錯(cuò)了。我們來(lái)體會(huì)一下它的壞味道：除了不符合上面的懶人原則外，這里還有一個(gè)非常不好的編碼習(xí)慣，即調(diào)用者隱藏了實(shí)參類(lèi)型，這是非常危險(xiǎn)的，不僅僅調(diào)用者需要“猜測(cè)”該調(diào)用哪個(gè)方法，而且被調(diào)用者也可能產(chǎn)生內(nèi)部邏輯混亂的情況。對(duì)于本例來(lái)說(shuō)應(yīng)該做如下修改：publicstaticvoidmain（String[]args）{Clientclient=newClient（）；String[]strs=null；client.methodA（"China"，strs）；}也就是說(shuō)讓編譯器知道這個(gè)null值是String類(lèi)型的，編譯即可順利通過(guò)，也就減少了錯(cuò)誤的發(fā)生。建議6：覆寫(xiě)變長(zhǎng)方法也循規(guī)蹈矩在Java中，子類(lèi)覆寫(xiě)父類(lèi)中的方法很常見(jiàn)，這樣做既可以修正Bug也可以提供擴(kuò)展的業(yè)務(wù)功能支持，同時(shí)還符合開(kāi)閉原則（Open-ClosedPrinciple），我們來(lái)看一下覆寫(xiě)必須滿足的條件：重寫(xiě)方法不能縮小訪問(wèn)權(quán)限。參數(shù)列表必須與被重寫(xiě)方法相同。返回類(lèi)型必須與被重寫(xiě)方法的相同或是其子類(lèi)。重寫(xiě)方法不能拋出新的異常，或者超出父類(lèi)范圍的異常，但是可以拋出更少、更有限的異常，或者不拋出異常。估計(jì)你已經(jīng)猜測(cè)出下面要講的內(nèi)容了，為什么“參數(shù)列表必須與被重寫(xiě)方法的相同”采用不同的字體，這其中是不是有什么玄機(jī)？是的，還真有那么一點(diǎn)點(diǎn)小玄機(jī)。參數(shù)列表相同包括三層意思：參數(shù)數(shù)量相同、類(lèi)型相同、順序相同，看上去好像沒(méi)什么問(wèn)題，那我們來(lái)看一個(gè)例子，業(yè)務(wù)場(chǎng)景與上一個(gè)建議相同，商品打折，代碼如下：publicclassClient{publicstaticvoidmain（String[]args）{//向上轉(zhuǎn)型Basebase=newSub（）；base.fun（100，50）；//不轉(zhuǎn)型Subsub=newSub（）；sub.fun（100，50）；}}//基類(lèi)classBase{voidfun（intprice,int……discounts）{System.out.println（"Base……fun"）；}}//子類(lèi)，覆寫(xiě)父類(lèi)方法classSubextendsBase{@Overridevoidfun（intprice,int[]discounts）{System.out.println（"Sub……fun"）；}}請(qǐng)問(wèn)：該程序有問(wèn)題嗎？——編譯通不過(guò)。那問(wèn)題出在什么地方呢？@Override注解嗎？非也，覆寫(xiě)是正確的，因?yàn)楦割?lèi)的calPrice編譯成字節(jié)碼后的形參是一個(gè)int類(lèi)型的形參加上一個(gè)int數(shù)組類(lèi)型的形參，子類(lèi)的參數(shù)列表也與此相同，那覆寫(xiě)是理所當(dāng)然的了，所以加上@Override注解沒(méi)有問(wèn)題，只是Eclipse會(huì)提示這不是一種很好的編碼風(fēng)格。難道是"sub.fun（100,50）"這條語(yǔ)句？正解，確實(shí)是這條語(yǔ)句報(bào)錯(cuò)，提示找不到fun（int,int）方法。這太奇怪了：子類(lèi)繼承了父類(lèi)的所有屬性和方法，甭管是私有的還是公開(kāi)的訪問(wèn)權(quán)限，同樣的參數(shù)、同樣的方法名，通過(guò)父類(lèi)調(diào)用沒(méi)有任何問(wèn)題，通過(guò)子類(lèi)調(diào)用卻編譯通不過(guò)，為啥？難道是沒(méi)繼承下來(lái)？或者子類(lèi)縮小了父類(lèi)方法的前置條件？那如果是這樣，就不應(yīng)該覆寫(xiě)，@Override就應(yīng)該報(bào)錯(cuò)，真是奇妙的事情！事實(shí)上，base對(duì)象是把子類(lèi)對(duì)象Sub做了向上轉(zhuǎn)型，形參列表是由父類(lèi)決定的，由于是變長(zhǎng)參數(shù)，在編譯時(shí)，"base.fun（100,50）"中的“50”這個(gè)實(shí)參會(huì)被編譯器“猜測(cè)”而編譯成“{50}”數(shù)組，再由子類(lèi)Sub執(zhí)行。我們?cè)賮?lái)看看直接調(diào)用子類(lèi)的情況，這時(shí)編譯器并不會(huì)把“50”做類(lèi)型轉(zhuǎn)換，因?yàn)閿?shù)組本身也是一個(gè)對(duì)象，編譯器還沒(méi)有聰明到要在兩個(gè)沒(méi)有繼承關(guān)系的類(lèi)之間做轉(zhuǎn)換，要知道Java是要求嚴(yán)格的類(lèi)型匹配的，類(lèi)型不匹配編譯器自然就會(huì)拒絕執(zhí)行，并給予錯(cuò)誤提示。這是個(gè)特例，覆寫(xiě)的方法參數(shù)列表竟然與父類(lèi)不相同，這違背了覆寫(xiě)的定義，并且會(huì)引發(fā)莫名其妙的錯(cuò)誤。所以讀者在對(duì)變長(zhǎng)參數(shù)進(jìn)行覆寫(xiě)時(shí)，如果要使用此類(lèi)似的方法，請(qǐng)找個(gè)小黑屋仔細(xì)想想是不是一定要如此。注意覆寫(xiě)的方法參數(shù)與父類(lèi)相同，不僅僅是類(lèi)型、數(shù)量，還包括顯示形式。建議7：警惕自增的陷阱記得大學(xué)剛開(kāi)始學(xué)C語(yǔ)言時(shí)，老師就說(shuō)：自增有兩種形式，分別是i++和++i,i++表示的是先賦值后加1，++i是先加1后賦值，這樣理解了很多年也沒(méi)出現(xiàn)問(wèn)題，直到遇到如下代碼，我才懷疑我的理解是不是錯(cuò)了：publicclassClient{publicstaticvoidmain（String[]args）{intcount=0；for（inti=0；i＜10；i++）{count=count++；}System.out.println（"count="+count）；}}這個(gè)程序輸出的count等于幾？是count自加10次嗎？答案等于10？可以非常肯定地告訴你，答案錯(cuò)誤！運(yùn)行結(jié)果是count等于0。為什么呢？count++是一個(gè)表達(dá)式，是有返回值的，它的返回值就是count自加前的值，Java對(duì)自加是這樣處理的：首先把count的值（注意是值，不是引用）拷貝到一個(gè)臨時(shí)變量區(qū)，然后對(duì)count變量加1，最后返回臨時(shí)變量區(qū)的值。程序第一次循環(huán)時(shí)的詳細(xì)處理步驟如下：步驟1JVM把count值（其值是0）拷貝到臨時(shí)變量區(qū)。步驟2count值加1，這時(shí)候count的值是1。步驟3返回臨時(shí)變量區(qū)的值，注意這個(gè)值是0，沒(méi)修改過(guò)。步驟4返回值賦值給count，此時(shí)count值被重置成0。"count=count++"這條語(yǔ)句可以按照如下代碼來(lái)理解：publicstaticintmockAdd（intcount）{//先保存初始值inttemp=count；//做自增操作count=count+1；//返回原始值returntemp；}于是第一次循環(huán)后count的值還是0，其他9次的循環(huán)也是一樣的，最終你會(huì)發(fā)現(xiàn)count的值始終沒(méi)有改變，仍然保持著最初的狀態(tài)。此例中代碼作者的本意是希望count自增，所以想當(dāng)然地認(rèn)為賦值給自身就成了，不曾想掉到Java自增的陷阱中了。解決方法很簡(jiǎn)單，只要把"count=count++"修改為"count++"即可。該問(wèn)題在不同的語(yǔ)言環(huán)境有不同的實(shí)現(xiàn)：C++中"count=count++"與"count++"是等效的，而在PHP中則保持著與Java相同的處理方式。每種語(yǔ)言對(duì)自增的實(shí)現(xiàn)方式各不同，讀者有興趣可以多找?guī)追N語(yǔ)言測(cè)試一下，思考一下原理。下次如果看到某人T恤上印著"i=i++"，千萬(wàn)不要鄙視他，記住，能夠以不同的語(yǔ)言解釋清楚這句話的人絕對(duì)不簡(jiǎn)單，應(yīng)該表現(xiàn)出“如滔滔江水”般的敬仰，心理默念著“高人，絕世高人哪”。建議8：不要讓舊語(yǔ)法困擾你N多年前接手了一個(gè)除了源碼以外什么都沒(méi)有的項(xiàng)目，沒(méi)需求、沒(méi)文檔、沒(méi)設(shè)計(jì)，原創(chuàng)者也已鳥(niǎo)獸散了，我們只能通過(guò)閱讀源碼來(lái)進(jìn)行維護(hù)。期間，同事看到一段很“奇妙”的代碼，讓大家?guī)兔Ψ治?，代碼片段如下：publicclassClient{publicstaticvoidmain（String[]args）{//數(shù)據(jù)定義及初始化intfee=200；//其他業(yè)務(wù)處理saveDefault：save（fee）；//其他業(yè)務(wù)處理}staticvoidsaveDefault（）{}staticvoidsave（intfee）{}}該代碼的業(yè)務(wù)含義是計(jì)算交易的手續(xù)費(fèi)，最低手續(xù)費(fèi)是2元，其業(yè)務(wù)邏輯大致看懂了，但是此代碼非常神奇，"saveDefault:save（fee）"這句代碼在此處出現(xiàn)后，后續(xù)就再也沒(méi)有與此有關(guān)的代碼了，這做何解釋呢？更神奇的是，編譯竟然還沒(méi)有錯(cuò)，運(yùn)行也很正常。Java中竟然有冒號(hào)操作符，一般情況下，它除了在唯一一個(gè)三元操作符中存在外就沒(méi)有其他地方可用了呀。當(dāng)時(shí)連項(xiàng)目組里的高手也是一愣一愣的，翻語(yǔ)法書(shū)，也沒(méi)有介紹冒號(hào)操作符的內(nèi)容，而且，也不可能出現(xiàn)連括號(hào)都可以省掉的方法調(diào)用、方法級(jí)聯(lián)?。∵@也太牛了吧！隔壁做C項(xiàng)目的同事過(guò)來(lái)串門(mén)，看我們?cè)谟懻撨@個(gè)問(wèn)題，很驚奇地說(shuō)“耶，Java中還有標(biāo)號(hào)呀，我以為Java這么高級(jí)的語(yǔ)言已經(jīng)拋棄goto語(yǔ)句了……”，一語(yǔ)點(diǎn)醒夢(mèng)中人：項(xiàng)目的原創(chuàng)者是C語(yǔ)言轉(zhuǎn)過(guò)來(lái)的開(kāi)發(fā)人員，所以他把C語(yǔ)言的goto習(xí)慣也帶到項(xiàng)目中了，后來(lái)由于經(jīng)過(guò)N手交接，重構(gòu)了多次，到我們這里goto語(yǔ)句已經(jīng)被重構(gòu)掉了，但是跳轉(zhuǎn)標(biāo)號(hào)還保留著，估計(jì)上一屆的重構(gòu)者也是稀里糊涂的，不敢貿(mào)然修改，所以把這個(gè)重任留給了我們。goto語(yǔ)句中有著"doubleface"作用的關(guān)鍵字，它可以讓程序從多層的循環(huán)中跳出，不用一層一層地退出，類(lèi)似高樓著火了，來(lái)不及一樓一樓的下，goto語(yǔ)句就可以讓你"biu～"的一聲從十層樓跳到地面上。這點(diǎn)確實(shí)很好，但同時(shí)也帶來(lái)了代碼結(jié)構(gòu)混亂的問(wèn)題，而且程序跳來(lái)跳去讓人看著就頭暈，還怎么調(diào)試？！這樣做甚至?xí)[禍連連，比如標(biāo)號(hào)前后對(duì)象構(gòu)造或變量初始化，一旦跳到這個(gè)標(biāo)號(hào)，程序就不可想象了，所以Java中拋棄了goto語(yǔ)法，但還是保留了該關(guān)鍵字，只是不進(jìn)行語(yǔ)義處理而已，與此類(lèi)似的還有const關(guān)鍵字。Java中雖然沒(méi)有了goto關(guān)鍵字，但是擴(kuò)展了break和continue關(guān)鍵字，它們的后面都可以加上標(biāo)號(hào)做跳轉(zhuǎn)，完全實(shí)現(xiàn)了goto功能，同時(shí)也把goto的詬病帶了進(jìn)來(lái)，所以我們?cè)陂喿x大牛的開(kāi)源程序時(shí)，根本就看不到break或continue后跟標(biāo)號(hào)的情況，甚至是break和continue都很少看到，這是提高代碼可讀性的一劑良藥，舊語(yǔ)法就讓它隨風(fēng)而去吧！建議9：少用靜態(tài)導(dǎo)入從Java5開(kāi)始引入了靜態(tài)導(dǎo)入語(yǔ)法（importstatic），其目是為了減少字符輸入量，提高代碼的可閱讀性，以便更好地理解程序。我們先來(lái)看一個(gè)不使用靜態(tài)導(dǎo)入的例子，也就是一般導(dǎo)入：publicclassMathUtils{//計(jì)算圓面積publicstaticdoublecalCircleArea（doubler）{returnMath.PI*r*r；}//計(jì)算球面積publicstaticdoublecalBallArea（doubler）{return4*Math.PI*r*r；}}這是很簡(jiǎn)單的數(shù)學(xué)工具類(lèi)，我們?cè)谶@兩個(gè)計(jì)算面積的方法中都引入了java.lang.Math類(lèi)（該類(lèi)是默認(rèn)導(dǎo)入的）中的PI（圓周率）常量，而Math這個(gè)類(lèi)寫(xiě)在這里有點(diǎn)多余，特別是如果MathUtils中的方法比較多時(shí)，如果每次都要敲入Math這個(gè)類(lèi)，繁瑣且多余，靜態(tài)導(dǎo)入可解決此類(lèi)問(wèn)題，使用靜態(tài)導(dǎo)入后的程序如下：importstaticjava.lang.Math.PI；publicclassMathUtils{//計(jì)算圓面積publicstaticdoublecalCircleArea（doubler）{returnPI*r*r；}//計(jì)算球面積publicstaticdoublecalBallArea（doubler）{return4*PI*r*r；}}靜態(tài)導(dǎo)入的作用是把Math類(lèi)中的PI常量引入到本類(lèi)中，這會(huì)使程序更簡(jiǎn)單，更容易閱讀，只要看到PI就知道這是圓周率，不用每次都要把類(lèi)名寫(xiě)全了。但是，濫用靜態(tài)導(dǎo)入會(huì)使程序更難閱讀，更難維護(hù)。靜態(tài)導(dǎo)入后，代碼中就不用再寫(xiě)類(lèi)名了，但是我們知道類(lèi)是“一類(lèi)事物的描述”，缺少了類(lèi)名的修飾，靜態(tài)屬性和靜態(tài)方法的表象意義可以被無(wú)限放大，這會(huì)讓閱讀者很難弄清楚其屬性或方法代表何意，甚至是哪一個(gè)類(lèi)的屬性（方法）都要思考一番（當(dāng)然，IDE友好提示功能是另說(shuō)），特別是在一個(gè)類(lèi)中有多個(gè)靜態(tài)導(dǎo)入語(yǔ)句時(shí)，若還使用了*（星號(hào)）通配符，把一個(gè)類(lèi)的所有靜態(tài)元素都導(dǎo)入進(jìn)來(lái)了，那簡(jiǎn)直就是惡夢(mèng)。我們來(lái)看一段例子：importstaticjava.lang.Double.*；importstaticjava.lang.Math.*；importstaticjava.lang.Integer.*；importstaticjava.text.NumberFormat.*；publicclassClient{//輸入半徑和精度要求，計(jì)算面積publicstaticvoidmain（String[]args）{doubles=PI*parseDouble（args[0]）；NumberFormatnf=getInstance（）；nf.setMaximumFractionDigits（parseInt（args[1]））；formatMessage（nf.format（s））；}//格式化消息輸出publicstaticvoidformatMessage（Strings）{System.out.println（"圓面積是："+s）；}}就這么一段程序，看著就讓人火大：常量PI，這知道，是圓周率；parseDouble方法可能是Double類(lèi)的一個(gè)轉(zhuǎn)換方法，這看名稱也能猜測(cè)到。那緊接著的getInstance方法是哪個(gè)類(lèi)的？是Client本地類(lèi)？不對(duì)呀，沒(méi)有這個(gè)方法，哦，原來(lái)是NumberFormate類(lèi)的方法，這和formateMessage本地方法沒(méi)有任何區(qū)別了——這代碼也太難閱讀了，非機(jī)器不可閱讀。所以，對(duì)于靜態(tài)導(dǎo)入，一定要遵循兩個(gè)規(guī)則：不使用*（星號(hào)）通配符，除非是導(dǎo)入靜態(tài)常量類(lèi)（只包含常量的類(lèi)或接口）。方法名是具有明確、清晰表象意義的工具類(lèi)。何為具有明確、清晰表象意義的工具類(lèi)？我們來(lái)看看JUnit4中使用的靜態(tài)導(dǎo)入的例子，代碼如下：importstaticorg.junit.Assert.*；publicclassDaoTest{@TestpublicvoidtestInsert（）{//斷言assertEquals（"foo"，"foo"）；assertFalse（Boolean.FALSE）；}}我們從程序中很容易判斷出assertEquals方法是用來(lái)斷言兩個(gè)值是否相等的，assertFalse方法則是斷言表達(dá)式為假，如此確實(shí)減少了代碼量，而且代碼的可讀性也提高了，這也是靜態(tài)導(dǎo)入用到正確地方所帶來(lái)的好處。建議10：不要在本類(lèi)中覆蓋靜態(tài)導(dǎo)入的變量和方法如果一個(gè)類(lèi)中的方法及屬性與靜態(tài)導(dǎo)入的方法及屬性重名會(huì)出現(xiàn)什么問(wèn)題呢？我們先來(lái)看一個(gè)正常的靜態(tài)導(dǎo)入，代碼如下：importstaticjava.lang.Math.PI；importstaticjava.lang.Math.abs；publicclassClient{publicstaticvoidmain（String[]args）{System.out.println（"PI="+PI）；System.out.println（"abs（100）="+abs（-100））；}}很簡(jiǎn)單的例子，打印出靜態(tài)常量PI值，計(jì)算-100的絕對(duì)值?，F(xiàn)在的問(wèn)題是：如果我們?cè)贑lient類(lèi)中也定義了PI常量和abs方法，會(huì)出現(xiàn)什么問(wèn)題？代碼如下：importstaticjava.lang.Math.PI；importstaticjava.lang.Math.abs；publicclassClient{//常量名與靜態(tài)導(dǎo)入的PI相同publicfnalstaticStringPI="祖沖之"；//方法名與靜態(tài)導(dǎo)入的相同publicstaticintabs（intabs）{return0；}publicstaticvoidmain（String[]args）{System.out.println（"PI="+PI）；System.out.println（"abs（100）="+abs（-100））；}}以上代碼中，定義了一個(gè)PI字符串類(lèi)型的常量，又定義了一個(gè)abs方法，與靜態(tài)導(dǎo)入的相同。首先說(shuō)好消息：編譯器沒(méi)有報(bào)錯(cuò)，接下來(lái)是不好的消息了：我們不知道哪個(gè)屬性和哪個(gè)方法被調(diào)用了，因?yàn)槌Ａ棵头椒嗤?，到底調(diào)用了哪一個(gè)方法呢？我們運(yùn)行一下看看結(jié)果：PI=祖沖之a(chǎn)bs（100）=0很明顯是本地的屬性和方法被引用了，為什么不是Math類(lèi)中的屬性和方法呢？那是因?yàn)榫幾g器有一個(gè)“最短路徑”原則：如果能夠在本類(lèi)中查找到的變量、常量、方法，就不會(huì)到其他包或父類(lèi)、接口中查找，以確保本類(lèi)中的屬性、方法優(yōu)先。因此，如果要變更一個(gè)被靜態(tài)導(dǎo)入的方法，最好的辦法是在原始類(lèi)中重構(gòu)，而不是在本類(lèi)中覆蓋。建議11：養(yǎng)成良好習(xí)慣，顯式聲明UID我們編寫(xiě)一個(gè)實(shí)現(xiàn)了Serializable接口（序列化標(biāo)志接口）的類(lèi)，Eclipse馬上就會(huì)給一個(gè)黃色警告：需要增加一個(gè)SerialVersionID。為什么要增加？它是怎么計(jì)算出來(lái)的？有什么用？本章就來(lái)解釋該問(wèn)題。類(lèi)實(shí)現(xiàn)Serializable接口的目的是為了可持久化，比如網(wǎng)絡(luò)傳輸或本地存儲(chǔ)，為系統(tǒng)的分布和異構(gòu)部署提供先決支持條件。若沒(méi)有序列化，現(xiàn)在我們熟悉的遠(yuǎn)程調(diào)用、對(duì)象數(shù)據(jù)庫(kù)都不可能存在，我們來(lái)看一個(gè)簡(jiǎn)單的序列化類(lèi)：publicclassPersonimplementsSerializable{privateStringname；/*name屬性的getter/setter方法省略*/}這是一個(gè)簡(jiǎn)單JavaBean，實(shí)現(xiàn)了Serializable接口，可以在網(wǎng)絡(luò)上傳輸，也可以本地存儲(chǔ)然后讀取。這里我們以Java消息服務(wù)（JavaMessageService）方式傳遞該對(duì)象（即通過(guò)網(wǎng)絡(luò)傳遞一個(gè)對(duì)象），定義在消息隊(duì)列中的數(shù)據(jù)類(lèi)型為ObjectMessage，首先定義一個(gè)消息的生產(chǎn)者（Producer），代碼如下：publicclassProducer{publicstaticvoidmain（String[]args）throwsException{Personperson=newPerson（）；person.setName（"混世魔王"）；//序列化，保存到磁盤(pán)上SerializationUtils.writeObject（person）；}}這里引入了一個(gè)工具類(lèi)SerializationUtils，其作用是對(duì)一個(gè)類(lèi)進(jìn)行序列化和反序列化，并存儲(chǔ)到硬盤(pán)上（模擬網(wǎng)絡(luò)傳輸），其代碼如下：publicclassSerializationUtils{privatestaticStringFILE_NAME="c：/obj.bin"；//序列化publicstaticvoidwriteObject（Serializables）{try{ObjectOutputStreamoos=newObjectOutputStream（newFileOutputStream（FILE_NAME））；oos.writeObject（s）；oos.close（）；}catch（Exceptione）{e.printStackTrace（）；}}publicstaticObjectreadObject（）{Objectobj=null；//反序列化try{ObjectInputinput=newObjectInputStream（newFileInputStream（FILE_NAME））；obj=input.readObject（）；input.close（）；}catch（Exceptione）{e.printStackTrace（）；}returnobj；}}通過(guò)對(duì)象序列化過(guò)程，把一個(gè)對(duì)象從內(nèi)存塊轉(zhuǎn)化為可傳輸?shù)臄?shù)據(jù)流，然后通過(guò)網(wǎng)絡(luò)發(fā)送到消息消費(fèi)者（Consumer）那里，并進(jìn)行反序列化，生成實(shí)例對(duì)象，代碼如下：publicclassConsumer{publicstaticvoidmain（String[]args）throwsException{//反序列化Personp=（Person）SerializationUtils.readObject（）；System.out.println（"name="+p.getName（））；}}這是一個(gè)反序列化過(guò)程，也就是對(duì)象數(shù)據(jù)流轉(zhuǎn)換為一個(gè)實(shí)例對(duì)象的過(guò)程，其運(yùn)行后的輸出結(jié)果為：混世魔王。這太easy了，是的，這就是序列化和反序列化典型的demo。但此處隱藏著一個(gè)問(wèn)題：如果消息的生產(chǎn)者和消息的消費(fèi)者所參考的類(lèi)（Person類(lèi)）有差異，會(huì)出現(xiàn)何種神奇事件？比如：消息生產(chǎn)者中的Person類(lèi)增加了一個(gè)年齡屬性，而消費(fèi)者沒(méi)有增加該屬性。為啥沒(méi)有增加？！因?yàn)檫@是個(gè)分布式部署的應(yīng)用，你甚至都不知道這個(gè)應(yīng)用部署在何處，特別是通過(guò)廣播（broadcast）方式發(fā)送消息的情況，漏掉一兩個(gè)訂閱者也是很正常的。在這種序列化和反序列化的類(lèi)不一致的情形下，反序列化時(shí)會(huì)報(bào)一個(gè)InvalidClassException異常，原因是序列化和反序列化所對(duì)應(yīng)的類(lèi)版本發(fā)生了變化，JVM不能把數(shù)據(jù)流轉(zhuǎn)換為實(shí)例對(duì)象。接著刨根問(wèn)底：JVM是根據(jù)什么來(lái)判斷一個(gè)類(lèi)版本的呢？好問(wèn)題，通過(guò)SerialVersionUID，也叫做流標(biāo)識(shí)符（StreamUniqueIdentifier），即類(lèi)的版本定義的，它可以顯式聲明也可以隱式聲明。顯式聲明格式如下：privatestaticfinallongserialVersionUID=XXXXXL；而隱式聲明則是我不聲明，你編譯器在編譯的時(shí)候幫我生成。生成的依據(jù)是通過(guò)包名、類(lèi)名、繼承關(guān)系、非私有的方法和屬性，以及參數(shù)、返回值等諸多因子計(jì)算得出的，極度復(fù)雜，基本上計(jì)算出來(lái)的這個(gè)值是唯一的。serialVersionUID如何生成已經(jīng)說(shuō)明了，我們?cè)賮?lái)看看serialVersionUID的作用。JVM在反序列化時(shí)，會(huì)比較數(shù)據(jù)流中的serialVersionUID與類(lèi)的serialVersionUID是否相同，如果相同，則認(rèn)為類(lèi)沒(méi)有發(fā)生改變，可以把數(shù)據(jù)流load為實(shí)例對(duì)象；如果不相同，對(duì)不起，我JVM不干了，拋個(gè)異常InvalidClassException給你瞧瞧。這是一個(gè)非常好的校驗(yàn)機(jī)制，可以保證一個(gè)對(duì)象即使在網(wǎng)絡(luò)或磁盤(pán)中“滾過(guò)”一次，仍能做到“出淤泥而不染”，完美地實(shí)現(xiàn)類(lèi)的一致性。但是，有時(shí)候我們需要一點(diǎn)特例場(chǎng)景，例如：我的類(lèi)改變不大，JVM是否可以把我以前的對(duì)象反序列化過(guò)來(lái)？就是依靠顯式聲明serialVersionUID，向JVM撒謊說(shuō)“我的類(lèi)版本沒(méi)有變更”，如此，我們編寫(xiě)的類(lèi)就實(shí)現(xiàn)了向上兼容。我們修改一下上面的Person類(lèi)，代碼如下：publicclassPersonimplementsSerializable{privatestaticfnallongserialVersionUID=55799L；/*其他保持不變*/}剛開(kāi)始生產(chǎn)者和消費(fèi)者持有的Person類(lèi)版本一致，都是V1.0，某天生產(chǎn)者的Person類(lèi)版本變更了，增加了一個(gè)“年齡”屬性，升級(jí)為V2.0，而由于種種原因（比如程序員疏忽、升級(jí)時(shí)間窗口不同等）消費(fèi)端的Person還保持為V1.0版本，代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=5799L；privateintage；/*age、name的getter/setter方法省略*/}此時(shí)雖然生產(chǎn)者和消費(fèi)者對(duì)應(yīng)的類(lèi)版本不同，但是顯式聲明的serialVersionUID相同，反序列化也是可以運(yùn)行的，所帶來(lái)的業(yè)務(wù)問(wèn)題就是消費(fèi)端不能讀取到新增的業(yè)務(wù)屬性（age屬性）而已。通過(guò)此例，我們的反序列化實(shí)現(xiàn)了版本向上兼容的功能，使用V1.0版本的應(yīng)用訪問(wèn)了一個(gè)V2.0版本的對(duì)象，這無(wú)疑提高了代碼的健壯性。我們?cè)诰帉?xiě)序列化類(lèi)代碼時(shí)，隨手加上serialVersionUID字段，也不會(huì)給我們帶來(lái)太多的工作量，但它卻可以在關(guān)鍵時(shí)候發(fā)揮異乎尋常的作用。注意顯式聲明serialVersionUID可以避免對(duì)象不一致，但盡量不要以這種方式向JVM“撒謊”。建議12：避免用序列化類(lèi)在構(gòu)造函數(shù)中為不變量賦值我們知道帶有final標(biāo)識(shí)的屬性是不變量，也就是說(shuō)只能賦值一次，不能重復(fù)賦值，但是在序列化類(lèi)中就有點(diǎn)復(fù)雜了，比如有這樣一個(gè)類(lèi)：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=71282334L；//不變量publicfnalStringname="混世魔王"；}這個(gè)Person類(lèi)（此時(shí)V1.0版本）被序列化，然后存儲(chǔ)在磁盤(pán)上，在反序列化時(shí)name屬性會(huì)重新計(jì)算其值（這與static變量不同，static變量壓根就沒(méi)有保存到數(shù)據(jù)流中），比如name屬性修改成了“德天使”（版本升級(jí)為V2.0），那么反序列化對(duì)象的name值就是“德天使”。保持新舊對(duì)象的final變量相同，有利于代碼業(yè)務(wù)邏輯統(tǒng)一，這是序列化的基本規(guī)則之一，也就是說(shuō)，如果final屬性是一個(gè)直接量，在反序列化時(shí)就會(huì)重新計(jì)算。對(duì)這基本規(guī)則不多說(shuō)，我們要說(shuō)的是final變量另外一種賦值方式：通過(guò)構(gòu)造函數(shù)賦值。代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=91282334L；//不變量初始不賦值publicfinalStringname；//構(gòu)造函數(shù)為不變量賦值publicPerson（）{name="混世魔王"；}}這也是我們常用的一種賦值方式，可以把這個(gè)Person類(lèi)定義為版本V1.0，然后進(jìn)行序列化，看看有什么問(wèn)題沒(méi)有，序列化的代碼如下所示：publicclassSerialize{publicstaticvoidmain（String[]args）{//序列化以持久保存SerializationUtils.writeObject（newPerson（））；}}Person的實(shí)例對(duì)象保存到了磁盤(pán)上，它是一個(gè)貧血對(duì)象（承載業(yè)務(wù)屬性定義，但不包含其行為定義），我們做一個(gè)簡(jiǎn)單的模擬，修改一下name值代表變更，要注意的是serialVersionUID保持不變，修改后的代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=91282334L；//不變量初始不賦值publicfinalStringname；//構(gòu)造函數(shù)為不變量賦值publicPerson（）{name="德天使"；}}此時(shí)Person類(lèi)的版本是V2.0，但serialVersionUID沒(méi)有改變，仍然可以反序列化，其代碼如下：publicclassDeserialize{publicstaticvoidmain（String[]args）{//反序列化Personp=（Person）SerializationUtils.readObject（）；System.out.println（）；}}現(xiàn)在問(wèn)題來(lái)了：打印的結(jié)果是什么？是混世魔王還是德天使？答案即將揭曉，答案是：混世魔王。final類(lèi)型的變量不是會(huì)重新計(jì)算嗎？答案應(yīng)該是“德天使”才對(duì)啊，為什么會(huì)是“混世魔王”？這是因?yàn)檫@里觸及了反序列化的另一個(gè)規(guī)則：反序列化時(shí)構(gòu)造函數(shù)不會(huì)執(zhí)行。反序列化的執(zhí)行過(guò)程是這樣的：JVM從數(shù)據(jù)流中獲取一個(gè)Object對(duì)象，然后根據(jù)數(shù)據(jù)流中的類(lèi)文件描述信息（在序列化時(shí)，保存到磁盤(pán)的對(duì)象文件中包含了類(lèi)描述信息，注意是類(lèi)描述信息，不是類(lèi)）查看，發(fā)現(xiàn)是final變量，需要重新計(jì)算，于是引用Person類(lèi)中的name值，而此時(shí)JVM又發(fā)現(xiàn)name竟然沒(méi)有賦值，不能引用，于是它很“聰明”地不再初始化，保持原值狀態(tài)，所以結(jié)果就是“混世魔王”了。讀者不要以為這樣的情況很少發(fā)生，如果使用Java開(kāi)發(fā)過(guò)桌面應(yīng)用，特別是參與過(guò)對(duì)性能要求較高的項(xiàng)目（比如交易類(lèi)項(xiàng)目），那么很容易遇到這樣的問(wèn)題。比如一個(gè)C/S結(jié)構(gòu)的在線外匯交易系統(tǒng)，要求提供24小時(shí)的聯(lián)機(jī)服務(wù)，如果在升級(jí)的類(lèi)中有一個(gè)final變量是構(gòu)造函數(shù)賦值的，而且新舊版本還發(fā)生了變化，則在應(yīng)用請(qǐng)求熱切的過(guò)程中（非常短暫，可能只有30秒），很可能就會(huì)出現(xiàn)反序列化生成的final變量值與新產(chǎn)生的實(shí)例值不相同的情況，于是業(yè)務(wù)異常就產(chǎn)生了，情況嚴(yán)重的話甚至?xí)绊懡灰讛?shù)據(jù)，那可是天大的事故了。注意在序列化類(lèi)中，不使用構(gòu)造函數(shù)為final變量賦值。建議13：避免為final變量復(fù)雜賦值為final變量賦值還有一種方式：通過(guò)方法賦值，即直接在聲明時(shí)通過(guò)方法返回值賦值。還是以Person類(lèi)為例來(lái)說(shuō)明，代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=91282334L；//通過(guò)方法返回值為final變量賦值publicfnalStringname=initName（）；//初始化方法名publicStringinitName（）{return"混世魔王"；}}name屬性是通過(guò)initName方法的返回值賦值的，這在復(fù)雜類(lèi)中經(jīng)常用到，這比使用構(gòu)造函數(shù)賦值更簡(jiǎn)潔、易修改，那么如此用法在序列化時(shí)會(huì)不會(huì)有問(wèn)題呢？我們一起來(lái)看看。Person類(lèi)寫(xiě)好了（定義為V1.0版本），先把它序列化，存儲(chǔ)到本地文件，其代碼與上一建議的Serialize類(lèi)相同，不再贅述。現(xiàn)在，Person類(lèi)的代碼需要修改，initName的返回值也改變了，代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=91282334L；//通過(guò)方法返回值為final變量賦值publicfinalStringname=initName（）；//初始化方法名publicStringinitName（）{return"德天使"；}}上段代碼僅僅修改了initName的返回值（Person類(lèi)為V2.0版本），也就是說(shuō)通過(guò)new生成的Person對(duì)象的final變量值都是“德天使”。那么我們把之前存儲(chǔ)在磁盤(pán)上的實(shí)例加載上來(lái)，name值會(huì)是什么呢？結(jié)果是：混世魔王。很詫異，上一建議說(shuō)過(guò)final變量會(huì)被重新賦值，但是這個(gè)例子又沒(méi)有重新賦值，為什么？上個(gè)建議所說(shuō)final會(huì)被重新賦值，其中的“值”指的是簡(jiǎn)單對(duì)象。簡(jiǎn)單對(duì)象包括：8個(gè)基本類(lèi)型，以及數(shù)組、字符串（字符串情況很復(fù)雜，不通過(guò)new關(guān)鍵字生成String對(duì)象的情況下，final變量的賦值與基本類(lèi)型相同），但是不能方法賦值。其中的原理是這樣的，保存到磁盤(pán)上（或網(wǎng)絡(luò)傳輸）的對(duì)象文件包括兩部分：（1）類(lèi)描述信息包括包路徑、繼承關(guān)系、訪問(wèn)權(quán)限、變量描述、變量訪問(wèn)權(quán)限、方法簽名、返回值，以及變量的關(guān)聯(lián)類(lèi)信息。要注意的一點(diǎn)是，它并不是class文件的翻版，它不記錄方法、構(gòu)造函數(shù)、static變量等的具體實(shí)現(xiàn)。之所以類(lèi)描述會(huì)被保存，很簡(jiǎn)單，是因?yàn)槟苋ヒ材芑芈?，這保證反序列化的健壯運(yùn)行。（2）非瞬態(tài)（transient關(guān)鍵字）和非靜態(tài)（static關(guān)鍵字）的實(shí)例變量值注意，這里的值如果是一個(gè)基本類(lèi)型，好說(shuō)，就是一個(gè)簡(jiǎn)單值保存下來(lái)；如果是復(fù)雜對(duì)象，也簡(jiǎn)單，連該對(duì)象和關(guān)聯(lián)類(lèi)信息一起保存，并且持續(xù)遞歸下去（關(guān)聯(lián)類(lèi)也必須實(shí)現(xiàn)Serializable接口，否則會(huì)出現(xiàn)序列化異常），也就是說(shuō)遞歸到最后，其實(shí)還是基本數(shù)據(jù)類(lèi)型的保存。正是因?yàn)檫@兩點(diǎn)原因，一個(gè)持久化后的對(duì)象文件會(huì)比一個(gè)class類(lèi)文件大很多，有興趣的讀者可以自己寫(xiě)個(gè)Helloword程序檢驗(yàn)一下，其體積確實(shí)膨脹了不少?？偨Y(jié)一下，反序列化時(shí)final變量在以下情況下不會(huì)被重新賦值：通過(guò)構(gòu)造函數(shù)為final變量賦值。通過(guò)方法返回值為final變量賦值。final修飾的屬性不是基本類(lèi)型。建議14：使用序列化類(lèi)的私有方法巧妙解決部分屬性持久化問(wèn)題部分屬性持久化問(wèn)題看似很簡(jiǎn)單，只要把不需要持久化的屬性加上瞬態(tài)關(guān)鍵字（transient關(guān)鍵字）即可。這是一種解決方案，但有時(shí)候行不通。例如一個(gè)計(jì)稅系統(tǒng)和人力資源系統(tǒng)（HR系統(tǒng)）通過(guò)RMI（RemoteMethodInvocation，遠(yuǎn)程方法調(diào)用）對(duì)接，計(jì)稅系統(tǒng)需要從HR系統(tǒng)獲得人員的姓名和基本工資，以作為納稅的依據(jù)，而HR系統(tǒng)的工資分為兩部分：基本工資和績(jī)效工資，基本工資沒(méi)什么秘密，根據(jù)工作崗位和年限自己都可以計(jì)算出來(lái)，但績(jī)效工資卻是保密的，不能泄露到外系統(tǒng)，很明顯這是兩個(gè)相互關(guān)聯(lián)的類(lèi)。先來(lái)看薪水類(lèi)Salary類(lèi)的代碼：publicclassSalaryimplementsSerializable{privatestaticfinallongserialVersionUID=44663L；//基本工資privateintbasePay；//績(jī)效工資privateintbonus；publicSalary（int_basePay,int_bonus）{basePay=_basePay；bonus=_bonus；}/*getter/setter方法省略*/}Peron類(lèi)與Salary類(lèi)是關(guān)聯(lián)關(guān)系，代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=60407L；//姓名privateStringname；//薪水privateSalarysalary；publicPerson（String_name,Salary_salary）{name=_name；salary=_salary；}/*getter/setter方法省略*/}這是兩個(gè)簡(jiǎn)單的JavaBean，都實(shí)現(xiàn)了Serializable接口，都具備了持久化條件。首先計(jì)稅系統(tǒng)請(qǐng)求HR系統(tǒng)對(duì)某一個(gè)Person對(duì)象進(jìn)行序列化，把人員和工資信息傳遞到計(jì)稅系統(tǒng)中，代碼如下：publicclassSerialize{publicstaticvoidmain（String[]args）{//基本工資1000元，績(jī)效工資2500元Salarysalary=newSalary（1000，2500）；//記錄人員信息Personperson=newPerson（"張三"，salary）；//HR系統(tǒng)持久化，并傳遞到計(jì)稅系統(tǒng)SerializationUtils.writeObject（person）；}}在通過(guò)網(wǎng)絡(luò)傳送到計(jì)稅系統(tǒng)后，進(jìn)行反序列化，代碼如下：publicclassDeserialize{publicstaticvoidmain（String[]args）{//技術(shù)系統(tǒng)反序列化，并打印信息Personp=（Person）SerializationUtils.readObject（）；StringBuffersb=newStringBuffer（）；sb.append（"姓名："+p.getName（））；sb.append（"\t基本工資："+p.getSalary（）.getBasePay（））；sb.append（"\t績(jī)效工資："+p.getSalary（）.getBonus（））；System.out.println（sb）；}}打印出的結(jié)果很簡(jiǎn)單：姓名：張三基本工資：1000績(jī)效工資：2500。但是這不符合需求，因?yàn)橛?jì)稅系統(tǒng)只能從HR系統(tǒng)中獲得人員姓名和基本工資，而績(jī)效工資是不能獲得的，這是個(gè)保密數(shù)據(jù)，不允許發(fā)生泄露。怎么解決這個(gè)問(wèn)題呢？你可能馬上會(huì)想到四種方案：（1）在bonus前加上transient關(guān)鍵字這是一個(gè)方法，但不是一個(gè)好方法，加上transient關(guān)鍵字就標(biāo)志著Salary類(lèi)失去了分布式部署的功能，它可是HR系統(tǒng)最核心的類(lèi)了，一旦遭遇性能瓶頸，想再實(shí)現(xiàn)分布式部署就不可能了，此方案否定。（2）新增業(yè)務(wù)對(duì)象增加一個(gè)Person4Tax類(lèi)，完全為計(jì)稅系統(tǒng)服務(wù)，就是說(shuō)它只有兩個(gè)屬性：姓名和基本工資。符合開(kāi)閉原則，而且對(duì)原系統(tǒng)也沒(méi)有侵入性，只是增加了工作量而已。這是個(gè)方法，但不是最優(yōu)方法。（3）請(qǐng)求端過(guò)濾在計(jì)稅系統(tǒng)獲得Person對(duì)象后，過(guò)濾掉Salary的bonus屬性，方案可行但不合規(guī)矩，因?yàn)镠R系統(tǒng)中的Salary類(lèi)安全性竟然讓外系統(tǒng)（計(jì)稅系統(tǒng)）來(lái)承擔(dān)，設(shè)計(jì)嚴(yán)重失職。（4）變更傳輸契約例如改用XML傳輸，或者重建一個(gè)WebService服務(wù)?？梢宰觯杀咎?。可能有讀者會(huì)說(shuō)了，你都在說(shuō)別人的方案不好，你提供個(gè)優(yōu)秀的方案看看！好的，這就展示一個(gè)優(yōu)秀的方案。其中，實(shí)現(xiàn)了Serializable接口的類(lèi)可以實(shí)現(xiàn)兩個(gè)私有方法：writeObject和readObject，以影響和控制序列化和反序列化的過(guò)程。我們把Person類(lèi)稍做修改，看看如何控制序列化和反序列化，代碼如下：publicclassPersonimplementsSerializable{privatestaticfinallongserialVersionUID=60407L；//姓名privateStringname；//薪水privatetransientSalarysalary；publicPerson（String_name,Salary_salary）{name=_name；salary=_salary；}//序列化委托方法privatevoidwriteObject（java.io.ObjectOutputStreamout）throwsIOException{out.defaultWriteObject（）；out.writeInt（salary.getBasePay（））；}//反序列化時(shí)委托方法privatevoidreadObject（java.io.ObjectInputStreamin）throwsIOException,Class-NotFoundException{in.defaultReadObject（）；salary=newSalary（in.readInt（），0）；}}其他代碼不做任何改動(dòng)，我們先運(yùn)行看看，結(jié)果為：姓名：張三基本工資：1000績(jī)效工資：0。我們?cè)赑erson類(lèi)中增加了writeObject和readObject兩個(gè)方法，并且訪問(wèn)權(quán)限都是私有級(jí)別，為什么這會(huì)改變程序的運(yùn)行結(jié)果呢？其實(shí)這里使用了序列化獨(dú)有的機(jī)制：序列化回調(diào)。Java調(diào)用ObjectOutputStream類(lèi)把一個(gè)對(duì)象轉(zhuǎn)換成流數(shù)據(jù)時(shí)，會(huì)通過(guò)反射（Reflection）檢查被序列化的類(lèi)是否有writeObject方法，并且檢查其是否符合私有、無(wú)返回值的特性。若有，則會(huì)委托該方法進(jìn)行對(duì)象序列化，若沒(méi)有，則由ObjectOutputStream按照默認(rèn)規(guī)則繼續(xù)序列化。同樣，在從流數(shù)據(jù)恢復(fù)成實(shí)例對(duì)象時(shí)，也會(huì)檢查是否有一個(gè)私有的readObject方法，如果有，則會(huì)通過(guò)該方法讀取屬性值。此處有幾個(gè)關(guān)鍵點(diǎn)要說(shuō)明：（1）out.defaultWriteObject（）告知JVM按照默認(rèn)的規(guī)則寫(xiě)入對(duì)象，慣例的寫(xiě)法是寫(xiě)在第一句話里。（2）in.defaultReadObject（）告知JVM按照默認(rèn)規(guī)則讀入對(duì)象，慣例的寫(xiě)法也是寫(xiě)在第一句話里。（3）out.writeXX和in.readXX分別是寫(xiě)入和讀出相應(yīng)的值，類(lèi)似一個(gè)隊(duì)列，先進(jìn)先出，如果此處有復(fù)雜的數(shù)據(jù)邏輯，建議按封裝Collection對(duì)象處理。可能有讀者會(huì)提出，這似乎不是一種優(yōu)雅的處理方案呀，為什么JDK沒(méi)有對(duì)此提供一個(gè)更好的解決辦法呢？比如訪問(wèn)者模式，或者設(shè)置鉤子函數(shù)（Hook），完全可以更優(yōu)雅地解決此類(lèi)問(wèn)題。我查閱了大量的文檔，得出的結(jié)論是：無(wú)解，只能說(shuō)這是一個(gè)可行的解決方案而已。再回到我們的業(yè)務(wù)領(lǐng)域，通過(guò)上述方法重構(gòu)后，其代碼的修改量減少了許多，也優(yōu)雅了許多?？赡苣阌忠磫?wèn)了：如此一來(lái)，Person類(lèi)也失去了分布式部署的能力啊。確實(shí)是，但是HR系統(tǒng)的難點(diǎn)和重點(diǎn)是薪水計(jì)算，特別是績(jī)效工資，它所依賴的參數(shù)很復(fù)雜（僅從數(shù)量上說(shuō)就有上百甚至上千種），計(jì)算公式也不簡(jiǎn)單（一般是引入腳本語(yǔ)言，個(gè)性化公式定制），而相對(duì)來(lái)說(shuō)Person類(lèi)基本上都是“靜態(tài)”屬性，計(jì)算的可能性不大，所以即使為性能考慮，Person類(lèi)為分布式部署的意義也不大。建議15：break萬(wàn)萬(wàn)不可忘我們經(jīng)常會(huì)寫(xiě)一些轉(zhuǎn)換類(lèi)，比如貨幣轉(zhuǎn)換、日期轉(zhuǎn)換、編碼轉(zhuǎn)換等，在金融領(lǐng)域里用到最多的要數(shù)中文數(shù)字轉(zhuǎn)換了，比如把“1”轉(zhuǎn)換為“壹”，不過(guò)，開(kāi)源世界是不會(huì)提供此工具類(lèi)的，因?yàn)樗N合中國(guó)文化了，要轉(zhuǎn)換還是得自己動(dòng)手寫(xiě)，代碼片段如下：publicclassClient{publicstaticvoidmain（String[]args）{System.out.println（"2="+toChineseNumberCase（2））；}//把阿拉伯?dāng)?shù)字翻譯成中文大寫(xiě)數(shù)字publicstaticStringtoChineseNumberCase（intn）{StringchineseNumber=""；switch（n）{case0：chineseNumber="零"；case1：chineseNumber="壹"；case2：chineseNumber="貳"；case3：chineseNumber="叁"；case4：chineseNumber="肆"；case5：chineseNumber="伍"；case6：chineseNumber="陸"；case7：chineseNumber="柒"；case8：chineseNumber="捌"；case9：chineseN