建站
咨詢
售后
建站咨詢
新聞中心
混沌之初
在進(jìn)行程序開(kāi)發(fā)的過(guò)程中，我們有時(shí)會(huì)看到這樣的Java類：
創(chuàng)新互聯(lián)網(wǎng)絡(luò)公司擁有十年的成都網(wǎng)站開(kāi)發(fā)建設(shè)經(jīng)驗(yàn)，上千多家客戶的共同信賴。提供成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營(yíng)銷(xiāo)網(wǎng)站建設(shè)、網(wǎng)站開(kāi)發(fā)、網(wǎng)站定制、買(mǎi)友情鏈接、建網(wǎng)站、網(wǎng)站搭建、響應(yīng)式網(wǎng)站開(kāi)發(fā)、網(wǎng)頁(yè)設(shè)計(jì)師打造企業(yè)風(fēng)格，提供周到的售前咨詢和貼心的售后服務(wù)
- 有上百個(gè)公共方法
- 單個(gè)方法好幾百行
- 整個(gè)Java文件幾千行
先下結(jié)論，這樣的類顯然是不好的。盡管他勉強(qiáng)能維持當(dāng)前功能的運(yùn)行。但實(shí)際上它已經(jīng)無(wú)法在進(jìn)行功能上的擴(kuò)展了。我們對(duì)他能做的只有保守治療，在危樓上再添磚加瓦。
盡管大家都不愿意承認(rèn)自己是一片混沌的制造者，但實(shí)際上每一個(gè)巨型類的代碼都是由你我親手或間接締造的。
但是當(dāng)有一天我們意識(shí)到，這個(gè)類已經(jīng)太過(guò)巨大，需要進(jìn)行重構(gòu)的時(shí)候，我們需要一些方法論與準(zhǔn)則來(lái)幫助我們進(jìn)行判斷。
好的類是什么樣的
在實(shí)際的開(kāi)發(fā)過(guò)程中，我們一眼就能判斷出來(lái)哪些類寫(xiě)得好，哪些類寫(xiě)的壞。我們可能不能明確地說(shuō)出來(lái)個(gè)所以然，但是就是能感覺(jué)出來(lái)。這種原因是：
優(yōu)秀的類可能精準(zhǔn)地展現(xiàn)出它所具備的能力。
在我們進(jìn)行代碼編寫(xiě)的時(shí)候，無(wú)時(shí)無(wú)刻的會(huì)和類打交道。而類與類之間所表達(dá)出來(lái)的邏輯之間的依賴和交互則是我們要關(guān)注的重點(diǎn)。所以，當(dāng)我們看到一個(gè)類時(shí)無(wú)法輕松的判斷出來(lái)它是用于什么功能的，或者一不小心的誤判了它實(shí)際的功能的時(shí)候，那么這個(gè)類就是有問(wèn)題的。
以下我們針對(duì)哪些角度是可以幫助我們判斷一個(gè)類是否優(yōu)秀。
統(tǒng)一順序
我們?cè)谶M(jìn)行代碼編寫(xiě)的時(shí)候總是有各種各樣的規(guī)范，規(guī)范的目的并不是和實(shí)際的編碼人員對(duì)著干，主要目的在于減少團(tuán)隊(duì)中的溝通成本。所以對(duì)于編寫(xiě)類文件來(lái)說(shuō)，需要做的第一件事就是要統(tǒng)一所有類中內(nèi)容的排列順序。這樣做有兩個(gè)好處：
- 減少在編寫(xiě)文件時(shí)候的位置考慮成本。
- 減少在閱讀代碼時(shí)的理解成本。
顯然我們更加關(guān)注的是第二點(diǎn)。具體來(lái)說(shuō)我們要保證類的屬性在一起、類的方法在一起，以便在我們進(jìn)行代碼閱讀的時(shí)候不會(huì)錯(cuò)過(guò)關(guān)鍵信息(我們更多的時(shí)候是簡(jiǎn)單瀏覽一下類的全貌，然后就徑直的去找我們關(guān)注的內(nèi)容)。同時(shí)一般來(lái)說(shuō)，我們按照以下順序來(lái)編寫(xiě)類：
- 公共靜態(tài)常量
- 私有靜態(tài)常量
- 私有靜態(tài)變量(不太應(yīng)該有共有變量)
- 公有方法
- 公有方法所用到的私有方法
總的來(lái)說(shuō)，我們應(yīng)該把屬性放到類的上面，而把方法放到類的下面，并將私有方法放到所調(diào)用的公有方法下面(可以參考《如何寫(xiě)好一個(gè)方法》)。這樣便于在閱讀類中內(nèi)容的時(shí)候可以從上到下逐步地了解類中的細(xì)節(jié)，符合我們自頂向下的閱讀習(xí)慣。
單一職責(zé)
我們有時(shí)候會(huì)覺(jué)得類可能太長(zhǎng)了。有很多的原因會(huì)讓我們有這樣的想法，而其中比較重要的一個(gè)原因是：這個(gè)類同時(shí)承擔(dān)了復(fù)數(shù)個(gè)功能。
我們?cè)谶M(jìn)行面向?qū)ο缶幊痰臅r(shí)候的主要方式是將擁有一些能力的對(duì)象用類的形式定義出來(lái)，這些能力就是類的方法。舉個(gè)例子：可以播放音樂(lè)的音箱，那么我們就可以創(chuàng)建一個(gè)音箱的類，然后其中有一個(gè)方法播放音樂(lè)。目前這個(gè)類是很好理解的，我們有一個(gè)音箱類，然后通過(guò)音箱類來(lái)實(shí)例化對(duì)象就可以得到一個(gè)音箱，通過(guò)調(diào)用音箱中的播放方法就可以播放音樂(lè)。但隨著功能的擴(kuò)充，或許我們的音箱變成了移動(dòng)音箱(注意，我們只有一個(gè)音箱)，而且增加了一個(gè)充電功能，于是我們?yōu)檫@個(gè)類增加了一個(gè)充電方法。
隨著功能不斷地開(kāi)發(fā)，我們可能會(huì)為音箱類中增加許多的與其有關(guān)聯(lián)的事物，我們可能在音箱類中添加：充電、顯示時(shí)間、定時(shí)關(guān)閉、隨機(jī)播放等等工呢功能。在不斷地迭代之后這個(gè)類會(huì)變得非常的臃腫，但是判斷臃腫與否的條件，便是是否單一職責(zé)。
盡管單一職責(zé)的這個(gè)概念比較容易理解，但是在實(shí)際操作的時(shí)候卻沒(méi)有一個(gè)明確的邊界，也就是說(shuō)要憑感覺(jué)。就比如上文中的音箱的例子，如果在只有充電和播放音樂(lè)的這種情況下，我們也可以將其寫(xiě)入到一個(gè)類中。但是如果功能變多，比如增加了電量展示、涓流充電等功能，那顯然我們更應(yīng)該把這些方法放到一個(gè)電池的類中，并將電量的屬性也放進(jìn)去。
所以從可實(shí)施的角度上來(lái)說(shuō)的話，我們可以通過(guò)兩種方法來(lái)幫我判斷這個(gè)方法是否滿足單一職責(zé)：
- 能否為方法起一個(gè)合適的名字
- 能否通過(guò)句簡(jiǎn)短的話來(lái)描述其功能。
解釋來(lái)說(shuō)，如果無(wú)法用一個(gè)對(duì)象名來(lái)描述這個(gè)類的話，而只能通過(guò)一些通用概念(如處理器、執(zhí)行器、管理器)來(lái)對(duì)他進(jìn)行描述的話，就說(shuō)明這個(gè)類的功能并不單一(當(dāng)然如果本身代碼規(guī)范就是這么定義的就另當(dāng)別論)。而如果無(wú)法用一兩句話來(lái)描述類的功能，或者必須用大量的“與”、“或”等詞來(lái)對(duì)描述做串聯(lián)，就說(shuō)明其承擔(dān)了太多的功能了，我們應(yīng)該將其拆分一下。
內(nèi)聚
我們?cè)谶M(jìn)行面對(duì)對(duì)象編程的時(shí)候經(jīng)常說(shuō)的就是類需要“高內(nèi)聚、低耦合”。我們把類中的方法操作類中的屬性稱做方法與屬性的關(guān)聯(lián)的話，那么關(guān)聯(lián)越多的類就是越內(nèi)聚的。極端一點(diǎn)的話，如果類內(nèi)所有的方法都使用所有的類屬性的話，那么這個(gè)類是最為內(nèi)聚的。實(shí)際情況并不總是如此理想，所以我們可以根據(jù)這種關(guān)聯(lián)關(guān)系來(lái)判斷類中的內(nèi)容是否足夠內(nèi)聚。
所以，如果你發(fā)現(xiàn)在在寫(xiě)完類了之后部分方法只與部分屬性產(chǎn)生關(guān)聯(lián)，而其他方法則與另外的屬性產(chǎn)生關(guān)聯(lián)，就說(shuō)明這兩部分之間是沒(méi)有內(nèi)聚性的。那么我們就可以將其拆分為兩個(gè)類，而這兩個(gè)類之間將更加的內(nèi)聚：方法與屬性互相依賴稱為了一個(gè)整體。
當(dāng)我們通過(guò)內(nèi)聚性來(lái)分析類后，可能會(huì)將一個(gè)大類，拆分為多個(gè)小類。這樣會(huì)增加類的數(shù)量從而增加類的復(fù)雜性，同時(shí)也會(huì)讓整體的代碼變多。但是類本身可以通過(guò)包路徑來(lái)進(jìn)行分類，所以這種拆分我認(rèn)為是比較合理的。
可擴(kuò)展
對(duì)于一些有擴(kuò)展需求的類，盡管他們可能滿足單一職責(zé)以及內(nèi)聚屬性。但是由于這種類本身的擴(kuò)展性，導(dǎo)致我們會(huì)在新的業(yè)務(wù)需求的時(shí)候頻繁地對(duì)這種類進(jìn)行修改與新方法的增加。這種修改導(dǎo)致的問(wèn)題是在每一次修改代碼或者新增方法的時(shí)候都無(wú)法保證不會(huì)對(duì)原有的功能造成影響。雖然我們可以通過(guò)單元測(cè)試或者集成測(cè)試來(lái)驗(yàn)證我們的修改，但是這都會(huì)增加我們的工作量。
所以，對(duì)于可能會(huì)頻繁修改、并進(jìn)行業(yè)務(wù)追加的方法類，我們需要特別的為其保留擴(kuò)展性。我們可以通過(guò)實(shí)現(xiàn)統(tǒng)一接口或者繼承抽象類、父類的方法，來(lái)獲得多個(gè)不同擴(kuò)展能力的子類，而這些子類我們也可以通過(guò)策略模式或者責(zé)任鏈模式來(lái)組織。
對(duì)于類來(lái)說(shuō)，對(duì)其進(jìn)行擴(kuò)展總是好與對(duì)其直接進(jìn)行修改。
可測(cè)試
關(guān)于這個(gè)角度，其實(shí)是源于我的另一個(gè)問(wèn)題，就是在傳統(tǒng)的三層框架下，中間的service層我們是否需要編寫(xiě)一層接口(interface)。我原來(lái)的認(rèn)知是，實(shí)際上在絕大多數(shù)的情況，這個(gè)service我們是不會(huì)再進(jìn)行其他實(shí)現(xiàn)的，所以單獨(dú)寫(xiě)一個(gè)接口然后再增加對(duì)應(yīng)的Impl只會(huì)讓我們?cè)跀U(kuò)展方法的時(shí)候更加的繁瑣。
但是現(xiàn)在我發(fā)現(xiàn)了直接的用處，那就是：支持了單元測(cè)試的進(jìn)行。
如果我們直接依賴具體的細(xì)節(jié)，就會(huì)對(duì)我們的測(cè)試帶來(lái)挑戰(zhàn)。具體來(lái)說(shuō)，如果我們依賴于一個(gè)具體的類的實(shí)現(xiàn)的話，那么當(dāng)我們希望針對(duì)其中的細(xì)節(jié)進(jìn)行測(cè)試的話我們就要對(duì)細(xì)節(jié)之外的內(nèi)容進(jìn)行調(diào)整，可能包括：系統(tǒng)時(shí)間、數(shù)據(jù)庫(kù)字段等內(nèi)容。但如果我們是使用接口對(duì)servce進(jìn)行調(diào)用，那么在我們測(cè)試的時(shí)候就可以通過(guò)直接編寫(xiě)測(cè)試用的service來(lái)實(shí)現(xiàn)預(yù)期的返回內(nèi)容。從而大大簡(jiǎn)化進(jìn)行測(cè)試的難度。
我們通過(guò)接口降低了系統(tǒng)之間的耦合度，讓類之間的關(guān)系更好理解，也便于測(cè)試的進(jìn)行。而這也是我們的依賴倒置原則(DIP)，我們針對(duì)抽象編程，讓其不依賴與具體細(xì)節(jié)，這樣當(dāng)我們需要調(diào)整細(xì)節(jié)的時(shí)候也不會(huì)影響上層內(nèi)容。
最后
我們?cè)赾oding的過(guò)程中總是在進(jìn)行類的編寫(xiě)，本篇文章對(duì)類的一些編寫(xiě)注意事項(xiàng)進(jìn)行了描述，在編寫(xiě)過(guò)程中主要需要注意類的：內(nèi)部屬性方法順序、類的職責(zé)是否單一、是否足夠內(nèi)聚、是否支持?jǐn)U展、是否可以進(jìn)行單元測(cè)試。盡管這并非全部需要注意的內(nèi)容，但如果可以根據(jù)這些引發(fā)思考便足夠了。
分享題目：一篇帶給你如何寫(xiě)好一個(gè)Java類？
文章起源：http://www.5511xx.com/article/cdspghe.html
