我曾經(jīng)在一次演講中，問過聽眾這樣一個問題：“一個方法的理想行數(shù)最多不超過多少行？”如果問一千個人，或許會有一千條答案吧。

　　這是一個見仁見智的問題。在《軟件開發(fā)沉思錄》一書中，ThoughtWorks的技術(shù)負責人Jeff Bay認為：“一個常見的原則是將方法的行數(shù)控制在5行之內(nèi)……”很多人對此感到不可思議。竊以為，關(guān)鍵不在于方法的最大行數(shù)，而是要合理理解方法的微粒度能為我們帶來什么好處？

　　Jeff Bay提倡“利用IDE提供的‘提取方法’功能，不斷地提取方法中的行為，直到它只有一級縮進為止。如果方法過長，不可能達到如此清晰的可讀性。”Robert C. Martin則強調(diào)：“方法的第一規(guī)則是要短小。第二條規(guī)則還要更短小。”

　　短小的方法更容易理解，更容易重用。這一點毋庸置疑。不過，短小的方法會導致方法數(shù)量的急劇增加，這會否對閱讀造成干擾？另一個顧慮則是我們在閱讀方法時，短小的方法必然會導致我們需要在方法之間跳來跳去。

　　這兩個問題，歸根結(jié)底還是方法命名的問題。只要方法名稱能夠清晰地表達其意圖，讀其名即可知其實，就沒有必要刨根問底追溯方法的內(nèi)部實現(xiàn)了。錢鍾書先生拒絕追慕者時，委婉地說道：“假如你吃了個雞蛋覺得不錯，何必認識那下蛋的母雞呢？”閱讀代碼遵循同樣的道理，如果你已經(jīng)從方法名稱中知曉它的意圖與職責，何必還要解剖方法體的內(nèi)部呢？而這正是封裝的意義。唯一的例外是你希望學習和挖掘?qū)崿F(xiàn)的內(nèi)部機制。

　　至于方法之間的跳轉(zhuǎn)問題，目前，許多IDE工具已經(jīng)提供了方便跳轉(zhuǎn)的功能。因此，不足為慮。

　　好的代碼應(yīng)該像一篇優(yōu)秀的散文，明白通暢，清新自然。寫文章要求專注于一件事，不要讓別的無關(guān)內(nèi)容干擾它。如果事情較為棘手，可以將一部分功能字斟句酌，分而治之。編寫可讀性強的代碼尤其需要重視構(gòu)成代碼的基本元素：方法。雖然在面向?qū)ο笤O(shè)計中，我們應(yīng)以對象的角度思考問題，但對于方法而言，我們?nèi)匀豢梢越梃b面向過程的設(shè)計，需要理清該方法履行職責的過程。就好似在心中繪制出方法的流程圖，對流程進行分解，并以各個方法代表每個步驟，就能寫出像散文一般的代碼。

　　一種常見的做法是在實現(xiàn)一個主要方法時，先不去實現(xiàn)具體的代碼，而是寫一些小方法的名稱，即首先完成主方法的模板框架，再分別實現(xiàn)構(gòu)成主方法的小方法。看似很難，實際上只要運用得當，就會使編碼變得更加輕松。它使得我們能夠從具體的方法實現(xiàn)中解放出來，先確定實現(xiàn)該功能的流程，再考慮每一步的具體實現(xiàn)。

　　例如，我要實現(xiàn)這樣一個方法，它需要通過傳入的ServletRequest對象，獲取某些信息，執(zhí)行步驟如下所示：
　　1）首先獲得ReportObject對象；
　　2）根據(jù)request對象收集必須的參數(shù)；
　　3）通過ReportObject對象以及收集獲得參數(shù)來組建一個ReportTable對象；
　　4）然后，將ReportTable設(shè)置給ExcelReportExporter對象；
　　5）最后，將ExcelReportExporter對象存儲到Session中。

　　我在編寫該方法時，并沒有實現(xiàn)每個步驟的具體細節(jié)，而是以各個小方法體現(xiàn)這些步驟，最后再利用Eclipse提供的功能，快速生成這些方法，并實現(xiàn)之。

public void saveReportExporter(ServletRequest request) {
    ReportObject reportObj = getReportObject(request);
    Map<String, Object> externalParams = collectExternalParams(request);
    ReportTable report = getReportTable(reportObj, externalParams);
    getReportExporterAndSaveToSession(report,request);
}         

        

        
        
      
        
it知識庫：重構(gòu)之美之一方法的長度，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。