|
這篇文章將與大家一起聊一聊，書寫整潔類的一些法則。 一、引言 以下引言的內(nèi)容，有必要伴隨這個(gè)系列的每一次更新，這次也不例外。 《代碼整潔之道》這本書提出了一個(gè)觀點(diǎn)：代碼質(zhì)量與其整潔度成正比，干凈的代碼，既在質(zhì)量上可靠，也為后期維護(hù)、升級(jí)奠定了良好基礎(chǔ)。書中介紹的規(guī)則均來自作者多年的實(shí)踐經(jīng)驗(yàn)，涵蓋從命名到重構(gòu)的多個(gè)編程方面，雖為一“家”之言，然誠有可資借鑒的價(jià)值。 但我們知道，很多時(shí)候，理想很豐滿，現(xiàn)實(shí)很骨感，也知道人在江湖，身不由己。因?yàn)轫?xiàng)目的緊迫性，需求的多樣性，我們無法時(shí)時(shí)刻刻都寫出整潔的代碼，保持自己輸出的都是高質(zhì)量、優(yōu)雅的代碼。 但若我們理解了代碼整潔之道的精髓，我們會(huì)知道怎樣讓自己的代碼更加優(yōu)雅、整潔、易讀、易擴(kuò)展，知道真正整潔的代碼應(yīng)該是怎么樣的，也許就會(huì)漸漸養(yǎng)成持續(xù)輸出整潔代碼的習(xí)慣。 而且或許你會(huì)發(fā)現(xiàn)，若你一直保持輸出整潔代碼的習(xí)慣，長期來看，會(huì)讓你的整體效率和代碼質(zhì)量大大提升。 二、本文涉及知識(shí)點(diǎn)思維導(dǎo)圖 國際慣例，先放出這篇文章所涉及內(nèi)容知識(shí)點(diǎn)的一張思維導(dǎo)圖，就開始正文。大家若是疲于閱讀文章正文，直接看這張圖，也是可以Get到本文的主要知識(shí)點(diǎn)的大概。 三、整潔類的書寫準(zhǔn)則 1 合理地分布類中的代碼 一般情況下，我們遵循變量列表在前，函數(shù)在后的原則。 類應(yīng)該從一組變量列表開始。若有公有靜態(tài)常量，應(yīng)該最先出現(xiàn)，然后是私有靜態(tài)變量，以及公有變量，私有變量。盡可能少的出現(xiàn)公有變量。 公共函數(shù)應(yīng)該出現(xiàn)在變量列表之后。我們喜歡把由某個(gè)公共函數(shù)調(diào)用的私有工具函數(shù)緊跟在公共函數(shù)后面。 這樣是符合自定向下的原則，讓程序讀起來像一篇報(bào)紙文章。 2 盡可能保持類的封裝 我們喜歡保持變量和工具函數(shù)的私有性，但不執(zhí)著于此。有時(shí)，我們需要用到protected變量或者工具，比如讓測試可以訪問到。然而，我們會(huì)盡可能使函數(shù)或變量保持私有，不對(duì)外暴露太多細(xì)節(jié)。放松封裝，總是下策。 3 類應(yīng)該短小 正如之前關(guān)于函數(shù)書寫的論調(diào)。類的一條規(guī)則是短小，第二條規(guī)則還是要短小。 和函數(shù)一樣，馬上有個(gè)問題要出現(xiàn)，那就是，多小合適呢? 對(duì)于函數(shù)，我們通過計(jì)算代碼行數(shù)來衡量大小，對(duì)于類，我們采用不同的衡量方法，那就是權(quán)責(zé)(responsibility)。 3.1 單一權(quán)責(zé)原則 單一權(quán)責(zé)(Single Responsibility Principle，SRP)認(rèn)為，類或模塊應(yīng)有且只有一條加以修改的理由。 舉個(gè)栗子，下面這個(gè)類足夠短小了嗎? [cpp] view plain copy print? public class SuperDashboard extends JFrameimplements MetaDataUser { public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() } 答案是否定的，這個(gè)類不夠“短小”。5個(gè)方法不算多，但是這個(gè)類雖方法少，但還是擁有太多權(quán)責(zé)。這個(gè)貌似很小的SuperDashboard類，卻有兩條關(guān)聯(lián)度并不大的加以修改的理由: 第一， 它跟蹤會(huì)隨著軟件每次發(fā)布而更新的版本信息(含有g(shù)etMajorVersionNumber等方法)。 第二，它還在管理組件(含有g(shù)etLastFocusedComponent方法)。 其實(shí)，鑒別權(quán)責(zé)(修改的理由)常常幫助我們?cè)诖a中認(rèn)識(shí)到并創(chuàng)建出更好的抽象。 我們可以輕易地將SuperDashboard拆解成名為Version的類中，而這個(gè)名為Version的類，極可能在其他應(yīng)用程序中得到復(fù)用： [cpp] view plain copy print? public class Version { public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() } 這樣，這個(gè)類就大致做到了單一權(quán)責(zé)。 4 合理提高類的內(nèi)聚性 我們希望類的內(nèi)聚性保持在較高的水平。 何為類的內(nèi)聚性?類的內(nèi)聚性就是類中變量與方法之間的依賴關(guān)系。類中方法操作的變量越多，就越黏聚到類上，就代表類的內(nèi)聚性高。 類應(yīng)該只有少量的實(shí)體變量，類中的每個(gè)方法都應(yīng)該操作一個(gè)或者多個(gè)這種變量。通常而言，如果一個(gè)類中的每個(gè)變量都被每個(gè)方法所使用，則該類具有最大的內(nèi)聚性。一般來說，創(chuàng)建這種極大化的內(nèi)聚類不可取，也不可能。 我們只希望內(nèi)聚性保持在較高的水平。內(nèi)聚性高，表示類中方法和變量相互依賴，相互結(jié)合成一個(gè)邏輯整體。 舉個(gè)高內(nèi)聚的例子： [cpp] view plain copy print? public class Stack { private int topOfStack = 0; List elements = new LinkedList(); public int size() { return topOfStack; } public void push(int element) { topOfStack++; elements.add(element); } public int pop() throws PoppedWhenEmpty { if (topOfStack == 0) throw new PoppedWhenEmpty(); int element = elements.get(--topOfStack); elements.remove(topOfStack); return element; } } 這個(gè)類非常內(nèi)聚，在三個(gè)方法中，僅有size()方法沒有使用所有的兩個(gè)變量。 注意，保持函數(shù)和參數(shù)短小的策略，有時(shí)候會(huì)導(dǎo)致為一組子集方法所用的實(shí)體變量增加。我們應(yīng)該嘗試將這些方法拆分到兩個(gè)或者多個(gè)類中，讓新的類更為內(nèi)聚。 5 有效地隔離修改 需求會(huì)改變，所以代碼也會(huì)改變。在面向?qū)ο笕腴T知識(shí)中我們學(xué)習(xí)到，具體類包含實(shí)現(xiàn)細(xì)節(jié)(代碼)，而抽象類則呈現(xiàn)概念。依賴于具體細(xì)節(jié)的客戶類，當(dāng)細(xì)節(jié)改變時(shí)，就會(huì)有風(fēng)險(xiǎn)。我們可以借助接口和抽象類來隔離這些細(xì)節(jié)帶來的影響。 舉個(gè)栗子，在一個(gè)設(shè)計(jì)場景下，我們以其設(shè)計(jì)直接依賴于TokyoStockExchange的Protfolio類，不如創(chuàng)建StockExchange接口，里面只聲明一個(gè)方法： [cpp] view plain copy print? public interface StockExchange { MoneycurrentPrice(String symbol); } 接著設(shè)計(jì)TokyoStockExchange類來實(shí)現(xiàn)這個(gè)接口： [cpp] view plain copy print? public class TokyoStockExchange extends StockExchange { //… } 我們還要確保Portfolio的構(gòu)造器接受作為參數(shù)StickExchange引用： [cpp] view plain copy print? public Portfolio { private StockExchange exchange; public Portfolio(StockExchange exchange) { this.exchange = exchange; } // ... } 那么現(xiàn)在就可以為StockExchange接口創(chuàng)建可以測試的實(shí)現(xiàn)了，例如返回固定的股票現(xiàn)值。比如測試購買5股微軟股票，我們下面的實(shí)現(xiàn)代碼返回100美元的現(xiàn)值，然后再實(shí)現(xiàn)一個(gè)總投資價(jià)值為500美元的測試，那么大概代碼則是： [cpp] view plain copy print? public class PortfolioTest { privateFixedStockExchangeStub exchange; privatePortfolio portfolio; @Before protected void setUp() throws Exception { exchange = new FixedStockExchangeStub(); exchange.fix("MSFT", 100); portfolio = new Portfolio(exchange); } @Test public void GivenFiveMSFTTotalShouldBe500() throws Exception { portfolio.add(5, "MSFT"); Assert.assertEquals(500,portfolio.value()); } } 如果系統(tǒng)解耦到足以這樣測試的程度，也就更加靈活，更加可復(fù)用。部件之間的解耦代表著系統(tǒng)中的元素相互隔離得很好。隔離也讓對(duì)系統(tǒng)每個(gè)元素的理解變得更加容易。 我們的Portfolio類不再是依賴于TokyoStockExchange類的實(shí)現(xiàn)細(xì)節(jié)，而是依賴于StockExchange接口這個(gè)抽象的概念，這樣就隔離了特定的細(xì)節(jié)。而其實(shí)我們的類就遵循了另一條類的設(shè)計(jì)原則，依賴倒置原則(Dependency Inversion Principle , DIP)，因?yàn)橐蕾嚨怪迷瓌t的本質(zhì)，實(shí)際上就是認(rèn)為類應(yīng)該依賴于抽象，而不是依賴于具體細(xì)節(jié)。 四、一些思考與總結(jié) 讓軟件能夠保持工作和讓軟件代碼整潔，是兩種截然不同的工作。我們中大多數(shù)人腦力有限，只能更多把更多精力放在讓代碼能夠工作上，而不是放在保持代碼有組織和整潔上。 問題是太多人在程序能夠正常工作時(shí)就以為萬事大吉了。我們沒能把思維轉(zhuǎn)向有關(guān)代碼組織和整潔的部分，我們只是一直在做新的需求，而不是回頭將臃腫的類切分為只有單一權(quán)責(zé)的去耦式單元。 與此同時(shí)，許多開發(fā)者害怕數(shù)量巨大的短小單一目的的類會(huì)導(dǎo)致難以一目了然抓住全局。他們認(rèn)為，要搞清楚一件較大的工作如果完成，就得在類與類之間找來找去。其實(shí)，有大量短小的類的系統(tǒng)并不比有少量龐大類的系統(tǒng)更難掌控。問題是：你是想把工具歸置于有許多抽屜、每個(gè)抽屜中裝有定義和標(biāo)記的良好組件的工具箱中呢，還是想要少數(shù)幾個(gè)能隨便把所有東西都扔進(jìn)去的抽屜呢?大概我們都更趨向于選擇前者。 每個(gè)達(dá)到一定規(guī)模的系統(tǒng)都包含大量邏輯和復(fù)雜性。管理這種復(fù)雜性的首要目標(biāo)就是加以組織，以便開發(fā)者能知道在哪里找到需要的內(nèi)容，專注于當(dāng)下工作直接相關(guān)的具體模塊。反之，擁有巨大、多目的類的系統(tǒng)，總是讓我們?cè)谀壳安⒉恍枰私獾囊淮蠖褨|西中艱難跋涉。 最終再強(qiáng)調(diào)一下：系統(tǒng)應(yīng)該由許多短小的類而不是少量巨大的類組成。每個(gè)小類封裝一個(gè)權(quán)責(zé)，只有一個(gè)修改的原因，并與少數(shù)其他類一起協(xié)同達(dá)成期望的系統(tǒng)行為。 五、本文涉及知識(shí)點(diǎn)提煉整理 原則一：合理地分布類中的代碼。 類中代碼的分布順序大致是： 1. 公有靜態(tài)常量 2. 私有靜態(tài)變量 3. 公有普通變量 4. 私有普通變量 5. 公共函數(shù) 6. 私有函數(shù) 原則二：盡可能地保持類的封裝。盡可能使函數(shù)或變量保持私有，不對(duì)外暴露太多細(xì)節(jié)。 原則三：類應(yīng)該短小，盡量保持單一權(quán)責(zé)原則。類或模塊應(yīng)有且只有一條加以修改的理由。 原則四：合理提高類的內(nèi)聚性。我們希望類的內(nèi)聚性保持在較高的水平。內(nèi)聚性高，表示類中方法和變量相互依賴，相互結(jié)合成一個(gè)邏輯整體。 原則五：有效地隔離修改。類應(yīng)該依賴于抽象，而不是依賴于具體細(xì)節(jié)。盡量對(duì)設(shè)計(jì)解耦，做好系統(tǒng)中的元素的相互隔離，做到更加靈活與可復(fù)用。 本文就此結(jié)束。 |
