隨著我們工程化經(jīng)驗(yàn)的增加，不知不覺(jué)的我們就會(huì)關(guān)心到這個(gè)問(wèn)題，模塊化，模塊設(shè)計(jì)就顯現(xiàn)出來(lái)，那到底什么是模塊化呢？

這不叫模塊化

我相信在很多時(shí)候，我們剛開(kāi)始從零開(kāi)始接手一個(gè)項(xiàng)目的時(shí)候，編碼之前總想著要實(shí)現(xiàn)什么的功能需要的模塊，然后要程序 模塊化，這種思想是值得認(rèn)同的，但往往我們并沒(méi)有做到真正的模塊化。 例如在一個(gè)需要很多外設(shè)接口，一般需要硬件初始化，相關(guān)配置，中斷服務(wù)程序，輸入輸出，邏輯處理等功能，我們的做法可能就是把代碼分布到多個(gè)文件和目錄里面，然后把這些目錄或者文件取名 xxxModule。 甚至把這些目錄分放在不同的倉(cāng)庫(kù)目錄里面，結(jié)果隨著編碼的增加，發(fā)現(xiàn)好多小功能都重復(fù)了，或者本可以寫(xiě)在一起的函數(shù)并沒(méi)有放在一起，導(dǎo)致我們的代碼思想不是很流暢，這樣做會(huì)誤導(dǎo)我們，甚至整個(gè)項(xiàng)目實(shí)現(xiàn)的思路。 究其原因這是因?yàn)槲覀兤鋵?shí)并不理解什么叫做 模塊，而僅僅是膚淺的把代碼切割開(kāi)來(lái)，分放在不同的位置，雖然這確實(shí)達(dá)到了部分模塊化的目的，但是也會(huì)制造一些不必要的麻煩。

什么是真正的模塊化？

真正的模塊化，并不是簡(jiǎn)單文本意義上的，而是與邏輯相關(guān)的有邏輯意義的。一個(gè)模塊應(yīng)該像一個(gè)集成電路芯片，我們能見(jiàn)到能使用的都很清晰，它定義了良好的輸入和輸出。 模塊是可能分開(kāi)地被編寫(xiě)的單位。這使他們可再用和允許廣泛人員同時(shí)協(xié)作、編寫(xiě)及研究不同的模塊。 實(shí)際上，編程語(yǔ)言已經(jīng)為我們提供了一種很好的模塊化方法，它的名字叫做 函數(shù)。每一個(gè)函數(shù)都有明確的 輸入（參數(shù)）和輸出（返回值），同一個(gè)文件里可以包含多個(gè)函數(shù)，所以你其實(shí)根本不需要把代碼分開(kāi)在多個(gè)文件或者目錄里面，同樣可以完成代碼的模塊化。 按照函數(shù)這個(gè)原則，我可以把代碼全都寫(xiě)在同一個(gè)文件里，卻仍然是非常模塊化的代碼，是不是覺(jué)得與之前的想法不一樣？ 是的，軟件編程模塊是一套一致而互相有緊密關(guān)聯(lián)的軟件組織， 每個(gè)模塊完成一個(gè)特定的子功能，所有的模塊按某種方法組裝起來(lái)，成為一個(gè)整體，完成整個(gè)系統(tǒng)所要求的功能，這就是真正的模塊化。

怎么模塊化？

我們知道了模塊化的原則與道理之后，就可以按照這個(gè)思路去開(kāi)發(fā)項(xiàng)目了，想要達(dá)到很好的模塊化，你需要做到以下幾點(diǎn)。我們從實(shí)現(xiàn)角度來(lái)說(shuō)。

避免寫(xiě)太長(zhǎng)的函數(shù)

一眼望去，如果一個(gè)函數(shù)的代碼你電腦一頁(yè)都看不完，那肯定是冗長(zhǎng)了或者不符合模塊化編程了。不需要滾屏就可以看得到全部的函數(shù)內(nèi)容，那對(duì)我們的理解也有幫助。 一般來(lái)說(shuō)一個(gè)函數(shù)最好不要超過(guò)40行代碼(當(dāng)然這個(gè)不是死規(guī)定，只是一個(gè)經(jīng)驗(yàn)建議而已)，如果寫(xiě)的函數(shù)太大了，就應(yīng)該把它拆分成幾個(gè)更小的函數(shù)。 也許你會(huì)說(shuō)到，這很難辦到，邏輯很多或者很多判斷條件的時(shí)候，40行往往不夠吧，那么其實(shí)我們也需要考慮到函數(shù)里面一些復(fù)雜的部分，是不是可以提取出來(lái)，單獨(dú)寫(xiě)一個(gè)小函數(shù)，再?gòu)脑瓉?lái)的函數(shù)里面調(diào)用。 另外函數(shù)層級(jí)也不要太多，比如一個(gè)函數(shù)長(zhǎng)成這樣：

      1void function(void* para)  2{  3 if (getOS().equals("MacOS")) {  4 a();  5 if(getOS().equals("AndroidOS")){  6 b();  7 if(getOS().equals("flymeOS")){  8 c();  9 } 10 } 11 } 12}  

我們看到這個(gè)函數(shù)由于很多的判斷，函數(shù)層級(jí)已經(jīng)超過(guò)4層了，這其實(shí)對(duì)我們的理解很不利，另一方面，一些邏輯變化也會(huì)導(dǎo)致我們的更改很麻煩，費(fèi)腦子。

每個(gè)函數(shù)只做一件簡(jiǎn)單的事情

有些人喜歡寫(xiě)一些 通用函數(shù)，一般我都放在 publicModule里面，既可以實(shí)現(xiàn)這個(gè)工又可以實(shí)現(xiàn)那個(gè)功能，它的內(nèi)部依據(jù)某些變量或者是某些條件，來(lái)選擇這個(gè)函數(shù)所要實(shí)現(xiàn)的小功能。 比如，寫(xiě)出這樣的函數(shù)：

      1void function() {  2 if (getOS().equals("MacOS")) {  3 a();  4 } else {  5 b();  6 }  7  8 c();  9 10 if (getOS().equals("MacOS")) { 11 d(); 12 } else { 13 e(); 14 } 15}  

這個(gè)函數(shù)，是想表達(dá)根據(jù)系統(tǒng)是否為MacOS，從而來(lái)做不同的事情。從這個(gè)函數(shù)可以很容易的看出，其實(shí)只有函數(shù)c()是兩種系統(tǒng)共有的，而其它的函數(shù) a(), b(), d(), e()都屬于不同的分支。 但是這種復(fù)用的寫(xiě)法其實(shí)是很不利的。如果一個(gè)函數(shù)可能實(shí)現(xiàn)2個(gè)功能，并且它們之間 共同點(diǎn)少于它們的不同點(diǎn)，那我們最好就寫(xiě)兩個(gè)不同的函數(shù)，否則這個(gè)函數(shù)的邏輯就不會(huì)很清晰，容易出現(xiàn)錯(cuò)誤。 不要害怕，函數(shù)簡(jiǎn)單點(diǎn)不丟人，我們不需要炫技。 好了，根據(jù)上面的說(shuō)法，這個(gè)函數(shù)可以改寫(xiě)成兩個(gè)函數(shù)：

     1void funMacOS() { 2 a(); 3 c(); 4 d(); 5}  

和

     1void funOther() { 2 b(); 3 c(); 4 e(); 5}  

如果我們發(fā)現(xiàn)兩件事情大部分內(nèi)容相同，只有少數(shù)不同，也就是說(shuō) 共同點(diǎn)大于它們的不同點(diǎn)，那就更簡(jiǎn)單了，我們可以把相同的部分提取出去，做成一個(gè) 輔助函數(shù)。 比如，如果有個(gè)函數(shù)是這樣：

      1void function() {  2  3 a();  4 b()  5 c();  6  7 if (getOS().equals("MacOS")) {  8 d();  9 } else { 10 e(); 11 } 12}  

其中函數(shù) a()，b()，c()都是一樣的，只有函數(shù) d()、e()根據(jù)系統(tǒng)有所不同。那么你可以把函數(shù) a()，b()，c()提取出去，代碼如下：

     1void preFun() { 2 a(); 3 b() 4 c(); 5}  

然后分別寫(xiě)兩個(gè)函數(shù)：

     1void funMacOS() { 2 preFun(); 3 d(); 4}  

和

     1void funOther() { 2 preFun(); 3 e(); 4}  

這樣更改之后，是不是清晰了很多，我們既共享了代碼，避免冗余，又做到了每個(gè)函數(shù)只做一件簡(jiǎn)單的事情。這樣的代碼，邏輯就更加清晰了。

工具函數(shù)

是的，我再說(shuō)一遍，每個(gè)函數(shù)只做一件簡(jiǎn)單的事情。但是有些時(shí)候在我們的工程代碼中，我們可能會(huì)發(fā)現(xiàn)其實(shí)里面有很多的重復(fù)。 所以一些常用的代碼，不管它有多短或者多么的簡(jiǎn)單，都可以提取出去做成函數(shù)，例如有些幫助函數(shù)也許就只有2行，但是我們把它封裝成一個(gè)函數(shù)的話(huà)，就能大大簡(jiǎn)化主要函數(shù)里面的邏輯。 也許你可能會(huì)說(shuō)，這些函數(shù)調(diào)用會(huì)增加代碼開(kāi)銷(xiāo)，但隨著硬件發(fā)展以及技術(shù)變革，這已經(jīng)是一種過(guò)時(shí)的觀(guān)念了。 現(xiàn)代的很多編譯器都能自動(dòng)的把小的函數(shù) 內(nèi)聯(lián)（inline）到調(diào)用它的地方，所以根本不會(huì)產(chǎn)生函數(shù)調(diào)用，也就不會(huì)產(chǎn)生任何多余的開(kāi)銷(xiāo)。 那么我可以使用宏來(lái)代替工具函數(shù)？一行代碼搞定了，比如

     1#define FillAndSendTxOptions( TRANSSEQ, ADDR, ID, LEN, TxO ) { \ 2afStatus_t stat;                                    \ 3ZDP_TxOptions = (TxO);                              \ 4stat = fillAndSend( (TRANSSEQ), (ADDR), (ID), (LEN) );          \ 5ZDP_TxOptions = AF_TX_OPTIONS_NONE;                 \ 6return stat;                                        \ 7}  

同樣，這也許也過(guò)時(shí)了，我不想讓宏（macro）來(lái)背這個(gè)鍋，在早期的C語(yǔ)言編譯器里，只有宏是靜態(tài)內(nèi)聯(lián)的，所以使用宏是為了達(dá)到內(nèi)聯(lián)的目的。 然而能否內(nèi)聯(lián)，其實(shí)并不是宏與函數(shù)的根本區(qū)別，這里我不細(xì)說(shuō)了，只要記住： 應(yīng)該盡量避免使用宏。如果想了解可以參考 避免這7個(gè)誤區(qū)，才能讓【宏】削鐵如泥 為了內(nèi)聯(lián)而使用宏，其實(shí)是濫用了宏，這會(huì)引起各種各樣的麻煩，比如使程序難以理解，難以調(diào)試，容易出錯(cuò)等等。

盡量使用局部變量和參數(shù)

我們應(yīng)該盡量避免使用全局變量和類(lèi)成員（class member）來(lái)傳遞信息，舉個(gè)例子：

      1class A {  2 String x;  3  4 void findX() {  5 ...  6 x = ...;  7 }  8  9 void fun() { 10 findX(); 11 ... 12 print(x); 13 } 14}  

首先，使用函數(shù)findX()，把一個(gè)值寫(xiě)入成員x。然后，調(diào)用x的值。這樣，x就變成了findX和print之間的數(shù)據(jù)通道。 由于 x屬于class A，這樣程序就失去了模塊化的結(jié)構(gòu)，與我們所說(shuō)的模塊化意義不符了。兩個(gè)函數(shù)依賴(lài)于成員x，就不再有明確的輸入和輸出，而是依賴(lài)全局的數(shù)據(jù)。 函數(shù)findX和fun不再能夠離開(kāi) class A而存在，具有依賴(lài)性，并且由于類(lèi)成員還有可能被其他代碼改變，這樣就會(huì)導(dǎo)致代碼變得復(fù)雜難以理解，函數(shù)的正確性也難以保證。 如果使用局部變量和參數(shù)來(lái)傳遞信息，那么這兩個(gè)函數(shù)就不需要依賴(lài)于某一個(gè)class，不易出錯(cuò)，代碼如下：

     1String findX() { 2 ... 3 x = ...; 4 return x; 5 } 6 void foo() { 7 String x = findX(); 8 print(x); 9 }  

總結(jié)

模塊化是指解決一個(gè)復(fù)雜問(wèn)題時(shí)，自頂向下，逐層把系統(tǒng)劃分成若干模塊的過(guò)程，深入理解模塊化，什么是真正的模塊化，那么我們才能夠事半功倍。 如果你喜歡我的文章表達(dá)的思維，轉(zhuǎn)發(fā)分享是對(duì)我的厚愛(ài)，期待您的點(diǎn)贊在看，下一期，再見(jiàn)！