1. 程式人生 > >如何寫出優雅的java程式碼

如何寫出優雅的java程式碼

一、不要使用魔法數字,儘量定義列舉、常量、巨集: 
我常常見到表示各種狀態的數字,0,1,2....,我真的不知道這表示什麼含義,如果 
你在不在文件中說明的話,這個東東過幾天連你自己都不知道個一二三了。 

二、命名要具有描述力,儘量使用全名而不是自創的縮寫,除非地球人都這麼用這個縮寫: 
我常常看到一些自創的縮寫,這個縮寫或許只有你自己知道,類名,方法名,引數名 
尤其要有好的描述裡,區域性變數尚可容忍。我寧可容忍超過40個字元的命令,也不願意 
看到只有一兩個字母的命名,當然迭代用的i,j除外。當然命名不要太長,太長說明你的類和 
方法要做的事情太多,請你拆分出更多細粒度功能單一的類和方法。 

三、同一類東東命名方式儘可能統一,比如類名使用大寫字母開頭的單詞,變數使用 

下劃線分割開來的小寫字母單詞,常量使用下滑線分割的開來的大寫字母單詞。不要 
交替使用。 

四、函式、類功能儘可能單一,不要試圖寫一個萬能/超級函式或者類。 
一個類和方法要有單一的職責,這樣的類和方法只做一件事,並且容易把他做好。 
1、不要試圖寫一個強大無比的方法。 
我常常看到一些試圖寫的多麼“精妙”無比多麼“強大”的函式,事實上不是什麼精妙,而是 
程式碼的臭味道。精妙強大無比萬能的方法往往你耗費大量精力去設計演算法,試圖覆蓋現在的各 
種可能,而無法面對將來新的需求,隨著新的需求,你的這個精妙的方法需要的修改並且改起來 
極其痛苦。在一次次的痛苦與精妙的演化中,你的方法越來越複雜,並且每一次修改你都會面 

臨影響以前功能的風險。這個方法使用者需要小心的處理你的精妙之處,如果沒有精妙傳遞好參 
數,那麼這個方法再也不精妙了,而是直接廢掉了。 
KISS(keep it simple and stupid)原理就是這個道理,你要使你的程式碼儘可能簡單,讓人 
看到有一目瞭然的清爽,而不是因為設計了一個精妙無比的萬能方法而沾沾自喜。這裡的簡單不是 
簡潔的代名字。有時候簡潔是那種傳說的“精妙”的程式碼。 
2、不要寫做多件事情的方法和類,你做一件事情,你就寫一個對應的方法,不要試圖通過引數來判定各種情況,然後做事情,並且做的事情和你方法描述的不一致。當你發現你的方法名字想不出來好的名字了,或者要加or和and了,那麼請你拆分出更多單一的方法。 

不要舉一些linux完成多種功能系統呼叫,這是被迫的,因為系統呼叫的數量是有限制的,它只有有限的空間來描述系統呼叫號和系統呼叫的對映表,不要在應用程式開發中效仿而誤以為優雅強大。我最噁心根據引數,然後一大堆的if..else 和switch..case判斷。 
五、不要修改已有的類和方法而是擴充套件它。 
這是程式設計的一個重要原則,開閉原則,在面向物件的語言中尤為重要。在面向過程中主要表現在,不要在一個函式要應對和這個函式相似的一個需求了,就在這個加個if,來修改這個方法,試圖重用和避免重複。而是要把公用的部分抽出來成一個小的功能函式,然後增加一個應對新的類似這個需求的處理方法。在面向物件中,例如使用策略模式、訪問者模式、Extend Object模式。 
六、不要重複你自己(DRY): 
程式最怕的是copy,paste,到處是重複的程式碼。copy,paste經常被誤以為快速完成需要用的功能的高效方式而被到處使用。你每重複一次,你就得負責保持他們的一致性,你就得在一處增加新的功能時,你就的把這個的功能加到其他地方。還在我剛會寫程式碼的時候去了一個小公司,他們的程式碼到處是copy,paste的痕跡,當要在現有的功能增加審計功能是,他們開始下命令了,每個人加幾行程式碼來做審計,真不知道那麼多人寫的審計版本,分散到那麼多處,這個審計功能是否可信有用。 
避免DRY的方法就是抽象,分離變化。不管是面向物件還是面向過程,分離變化並抽象之是最主要的設計原則。設計模式中的模板方法,我們常用的回撥都是我們常用的方法。 
我發現越是提供更多回調處理的語言和框架,就越具有靈活性和易用性。ruby語言之所以有如此的威力,主要是因為它提供了更多的回撥處理。它可以在動態的給一個類增加方法,這樣可以在超類中定義增加方法的方法,然後再子類呼叫,子類就具有無比的能力。它的block提供了強大的回撥機制,我只要不知道如何處理了我就yield出來,method missing機制更是神祕無比,你可以寫出像find_by_name_and_age,2.days.ago這樣像自然語言一樣易讀的程式碼。 

七、不要跨越邊界,在適合的地方寫程式碼。 
在分層的架構中,不要跨越層的邊界。例如web開發的三層架構: 
資料訪問層(DAO)、業務層(Service)、表現層。 
不要在業務層裸寫SQL來做事情,不要在業務層摻和進來表現層的東東,不要在表現層/控制器中寫業務的東東。既然已經分層了,那麼就要好好的遵守它,如果到處跨越邊界的話,那麼和不分層沒有什麼區別,使得每一層都不倫不類。例如你應該在業務層進行事務管理,而你的控制器到處是業務程式碼,那將無法控制。如果你的業務層到處是SQL,我不知道你的DAO存在的意義了。 
八、分層的web架構: 
DAO層最好按照模型來劃分dao類,如果業務很簡單,也可以將相關的模型合併為一個DAO。 
Service層,不要按照DAO和Service一一對應的方式劃分,而是要按照業務的類別和實際情況來劃分。事實上Service層通常是用來處理涉及到多個模型的業務,而涉及到一個模型的業務,常常被放在模型中,這是一種自然而更面向物件的設計方法。只有資料的模型被稱為貧血型模型,這種模型被認為是對面向物件的一種背離,而在模型中放置專有的業務方法,不僅有利於公用,而且模型更具有描述力。 
九、關於MVC: 
MVC是一種鬆耦合的設計方案,最容易誤用的就是控制器(c)。控制器只負責呼叫業務方法,準備好資料供View去展現。而不要把業務和如何展示的東東放在裡面。我常常看到有人在控制器中拼html片段和寫一些業務相關的程式碼。
十、順便說一下異常的使用。 
如果你是使用語言支援異常機制,那麼儘可能的使用異常機制和定義好與自己業務相關的異常,而不是通過返回值表示正確和錯誤。如果你使用的語言支援異常機制,請不要寫類linux下c似的程式碼形式,每寫一個函式,我就寫一個判斷返回值呼叫是否成功,嚴重分離了我對核心業務的關注。異常提供了優雅的處理錯誤的方法。 

總之,你在寫程式碼的時候,你儘量考慮使用你介面的人和閱讀你程式碼的人,不要讓他們不爽。 
先寫到這裡,希望對大家有所幫助

相關推薦

no