隨著我們工程化經(jīng)驗的增加,不知不覺的我們就會關(guān)心到這個問題,模塊化,模塊設(shè)計就顯現(xiàn)出來,那到底什么是模塊化呢?
這不叫模塊化
我相信在很多時候,我們剛開始從零開始接手一個項目的時候,編碼之前總想著要實現(xiàn)什么的功能需要的模塊,然后要程序 模塊化,這種思想是值得認同的,但往往我們并沒有做到真正的模塊化。 例如在一個需要很多外設(shè)接口,一般需要硬件初始化,相關(guān)配置,中斷服務(wù)程序,輸入輸出,邏輯處理等功能,我們的做法可能就是把代碼分布到多個文件和目錄里面,然后把這些目錄或者文件取名 xxxModule。 甚至把這些目錄分放在不同的倉庫目錄里面,結(jié)果隨著編碼的增加,發(fā)現(xiàn)好多小功能都重復(fù)了,或者本可以寫在一起的函數(shù)并沒有放在一起,導(dǎo)致我們的代碼思想不是很流暢,這樣做會誤導(dǎo)我們,甚至整個項目實現(xiàn)的思路。 究其原因這是因為我們其實并不理解什么叫做 模塊,而僅僅是膚淺的把代碼切割開來,分放在不同的位置,雖然這確實達到了部分模塊化的目的,但是也會制造一些不必要的麻煩。
什么是真正的模塊化?
真正的模塊化,并不是簡單文本意義上的,而是與邏輯相關(guān)的有邏輯意義的。一個模塊應(yīng)該像一個集成電路芯片,我們能見到能使用的都很清晰,它定義了良好的輸入和輸出。 模塊是可能分開地被編寫的單位。這使他們可再用和允許廣泛人員同時協(xié)作、編寫及研究不同的模塊。 實際上,編程語言已經(jīng)為我們提供了一種很好的模塊化方法,它的名字叫做 函數(shù)。每一個函數(shù)都有明確的 輸入(參數(shù))和輸出(返回值),同一個文件里可以包含多個函數(shù),所以你其實根本不需要把代碼分開在多個文件或者目錄里面,同樣可以完成代碼的模塊化。 按照函數(shù)這個原則,我可以把代碼全都寫在同一個文件里,卻仍然是非常模塊化的代碼,是不是覺得與之前的想法不一樣? 是的,軟件編程模塊是一套一致而互相有緊密關(guān)聯(lián)的軟件組織, 每個模塊完成一個特定的子功能,所有的模塊按某種方法組裝起來,成為一個整體,完成整個系統(tǒng)所要求的功能,這就是真正的模塊化。
怎么模塊化?
我們知道了模塊化的原則與道理之后,就可以按照這個思路去開發(fā)項目了,想要達到很好的模塊化,你需要做到以下幾點。我們從實現(xiàn)角度來說。
避免寫太長的函數(shù)
一眼望去,如果一個函數(shù)的代碼你電腦一頁都看不完,那肯定是冗長了或者不符合模塊化編程了。不需要滾屏就可以看得到全部的函數(shù)內(nèi)容,那對我們的理解也有幫助。 一般來說一個函數(shù)最好不要超過40行代碼(當然這個不是死規(guī)定,只是一個經(jīng)驗建議而已),如果寫的函數(shù)太大了,就應(yīng)該把它拆分成幾個更小的函數(shù)。 也許你會說到,這很難辦到,邏輯很多或者很多判斷條件的時候,40行往往不夠吧,那么其實我們也需要考慮到函數(shù)里面一些復(fù)雜的部分,是不是可以提取出來,單獨寫一個小函數(shù),再從原來的函數(shù)里面調(diào)用。 另外函數(shù)層級也不要太多,比如一個函數(shù)長成這樣:
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}
我們看到這個函數(shù)由于很多的判斷,函數(shù)層級已經(jīng)超過4層了,這其實對我們的理解很不利,另一方面,一些邏輯變化也會導(dǎo)致我們的更改很麻煩,費腦子。
每個函數(shù)只做一件簡單的事情
有些人喜歡寫一些 通用函數(shù),一般我都放在 publicModule里面,既可以實現(xiàn)這個工又可以實現(xiàn)那個功能,它的內(nèi)部依據(jù)某些變量或者是某些條件,來選擇這個函數(shù)所要實現(xiàn)的小功能。 比如,寫出這樣的函數(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}
這個函數(shù),是想表達根據(jù)系統(tǒng)是否為MacOS,從而來做不同的事情。從這個函數(shù)可以很容易的看出,其實只有函數(shù)c()是兩種系統(tǒng)共有的,而其它的函數(shù) a(), b(), d(), e()都屬于不同的分支。 但是這種復(fù)用的寫法其實是很不利的。如果一個函數(shù)可能實現(xiàn)2個功能,并且它們之間 共同點少于它們的不同點,那我們最好就寫兩個不同的函數(shù),否則這個函數(shù)的邏輯就不會很清晰,容易出現(xiàn)錯誤。 不要害怕,函數(shù)簡單點不丟人,我們不需要炫技。 好了,根據(jù)上面的說法,這個函數(shù)可以改寫成兩個函數(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ù)不同,也就是說 共同點大于它們的不同點,那就更簡單了,我們可以把相同的部分提取出去,做成一個 輔助函數(shù)。 比如,如果有個函數(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}
然后分別寫兩個函數(shù):
1void funMacOS() { 2 preFun(); 3 d(); 4}
和
1void funOther() { 2 preFun(); 3 e(); 4}
這樣更改之后,是不是清晰了很多,我們既共享了代碼,避免冗余,又做到了每個函數(shù)只做一件簡單的事情。這樣的代碼,邏輯就更加清晰了。
工具函數(shù)
是的,我再說一遍,每個函數(shù)只做一件簡單的事情。但是有些時候在我們的工程代碼中,我們可能會發(fā)現(xiàn)其實里面有很多的重復(fù)。 所以一些常用的代碼,不管它有多短或者多么的簡單,都可以提取出去做成函數(shù),例如有些幫助函數(shù)也許就只有2行,但是我們把它封裝成一個函數(shù)的話,就能大大簡化主要函數(shù)里面的邏輯。 也許你可能會說,這些函數(shù)調(diào)用會增加代碼開銷,但隨著硬件發(fā)展以及技術(shù)變革,這已經(jīng)是一種過時的觀念了。 現(xiàn)代的很多編譯器都能自動的把小的函數(shù) 內(nèi)聯(lián)(inline)到調(diào)用它的地方,所以根本不會產(chǎn)生函數(shù)調(diào)用,也就不會產(chǎn)生任何多余的開銷。 那么我可以使用宏來代替工具函數(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}
同樣,這也許也過時了,我不想讓宏(macro)來背這個鍋,在早期的C語言編譯器里,只有宏是靜態(tài)內(nèi)聯(lián)的,所以使用宏是為了達到內(nèi)聯(lián)的目的。 然而能否內(nèi)聯(lián),其實并不是宏與函數(shù)的根本區(qū)別,這里我不細說了,只要記?。?/span> 應(yīng)該盡量避免使用宏。如果想了解可以參考 避免這7個誤區(qū),才能讓【宏】削鐵如泥 為了內(nèi)聯(lián)而使用宏,其實是濫用了宏,這會引起各種各樣的麻煩,比如使程序難以理解,難以調(diào)試,容易出錯等等。
盡量使用局部變量和參數(shù)
我們應(yīng)該盡量避免使用全局變量和類成員(class member)來傳遞信息,舉個例子:
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(),把一個值寫入成員x。然后,調(diào)用x的值。這樣,x就變成了findX和print之間的數(shù)據(jù)通道。 由于 x屬于class A,這樣程序就失去了模塊化的結(jié)構(gòu),與我們所說的模塊化意義不符了。兩個函數(shù)依賴于成員x,就不再有明確的輸入和輸出,而是依賴全局的數(shù)據(jù)。 函數(shù)findX和fun不再能夠離開 class A而存在,具有依賴性,并且由于類成員還有可能被其他代碼改變,這樣就會導(dǎo)致代碼變得復(fù)雜難以理解,函數(shù)的正確性也難以保證。 如果使用局部變量和參數(shù)來傳遞信息,那么這兩個函數(shù)就不需要依賴于某一個class,不易出錯,代碼如下:
1String findX() { 2 ... 3 x = ...; 4 return x; 5 } 6 void foo() { 7 String x = findX(); 8 print(x); 9 }
總結(jié)
模塊化是指解決一個復(fù)雜問題時,自頂向下,逐層把系統(tǒng)劃分成若干模塊的過程,深入理解模塊化,什么是真正的模塊化,那么我們才能夠事半功倍。 如果你喜歡我的文章表達的思維,轉(zhuǎn)發(fā)分享是對我的厚愛,期待您的點贊在看,下一期,再見!
隨著我們工程化經(jīng)驗的增加,不知不覺的我們就會關(guān)心到這個問題,模塊化,模塊設(shè)計就顯現(xiàn)出來,那到底什么是模塊化呢?
這不叫模塊化
我相信在很多時候,我們剛開始從零開始接手一個項目的時候,編碼之前總想著要實現(xiàn)什么的功能需要的模塊,然后要程序 模塊化,這種思想是值得認同的,但往往我們并沒有做到真正的模塊化。 例如在一個需要很多外設(shè)接口,一般需要硬件初始化,相關(guān)配置,中斷服務(wù)程序,輸入輸出,邏輯處理等功能,我們的做法可能就是把代碼分布到多個文件和目錄里面,然后把這些目錄或者文件取名 xxxModule。 甚至把這些目錄分放在不同的倉庫目錄里面,結(jié)果隨著編碼的增加,發(fā)現(xiàn)好多小功能都重復(fù)了,或者本可以寫在一起的函數(shù)并沒有放在一起,導(dǎo)致我們的代碼思想不是很流暢,這樣做會誤導(dǎo)我們,甚至整個項目實現(xiàn)的思路。 究其原因這是因為我們其實并不理解什么叫做 模塊,而僅僅是膚淺的把代碼切割開來,分放在不同的位置,雖然這確實達到了部分模塊化的目的,但是也會制造一些不必要的麻煩。什么是真正的模塊化?
真正的模塊化,并不是簡單文本意義上的,而是與邏輯相關(guān)的有邏輯意義的。一個模塊應(yīng)該像一個集成電路芯片,我們能見到能使用的都很清晰,它定義了良好的輸入和輸出。 模塊是可能分開地被編寫的單位。這使他們可再用和允許廣泛人員同時協(xié)作、編寫及研究不同的模塊。 實際上,編程語言已經(jīng)為我們提供了一種很好的模塊化方法,它的名字叫做 函數(shù)。每一個函數(shù)都有明確的 輸入(參數(shù))和輸出(返回值),同一個文件里可以包含多個函數(shù),所以你其實根本不需要把代碼分開在多個文件或者目錄里面,同樣可以完成代碼的模塊化。 按照函數(shù)這個原則,我可以把代碼全都寫在同一個文件里,卻仍然是非常模塊化的代碼,是不是覺得與之前的想法不一樣? 是的,軟件編程模塊是一套一致而互相有緊密關(guān)聯(lián)的軟件組織, 每個模塊完成一個特定的子功能,所有的模塊按某種方法組裝起來,成為一個整體,完成整個系統(tǒng)所要求的功能,這就是真正的模塊化。怎么模塊化?
我們知道了模塊化的原則與道理之后,就可以按照這個思路去開發(fā)項目了,想要達到很好的模塊化,你需要做到以下幾點。我們從實現(xiàn)角度來說。避免寫太長的函數(shù)
一眼望去,如果一個函數(shù)的代碼你電腦一頁都看不完,那肯定是冗長了或者不符合模塊化編程了。不需要滾屏就可以看得到全部的函數(shù)內(nèi)容,那對我們的理解也有幫助。 一般來說一個函數(shù)最好不要超過40行代碼(當然這個不是死規(guī)定,只是一個經(jīng)驗建議而已),如果寫的函數(shù)太大了,就應(yīng)該把它拆分成幾個更小的函數(shù)。 也許你會說到,這很難辦到,邏輯很多或者很多判斷條件的時候,40行往往不夠吧,那么其實我們也需要考慮到函數(shù)里面一些復(fù)雜的部分,是不是可以提取出來,單獨寫一個小函數(shù),再從原來的函數(shù)里面調(diào)用。 另外函數(shù)層級也不要太多,比如一個函數(shù)長成這樣: 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}
我們看到這個函數(shù)由于很多的判斷,函數(shù)層級已經(jīng)超過4層了,這其實對我們的理解很不利,另一方面,一些邏輯變化也會導(dǎo)致我們的更改很麻煩,費腦子。
每個函數(shù)只做一件簡單的事情
有些人喜歡寫一些 通用函數(shù),一般我都放在 publicModule里面,既可以實現(xiàn)這個工又可以實現(xiàn)那個功能,它的內(nèi)部依據(jù)某些變量或者是某些條件,來選擇這個函數(shù)所要實現(xiàn)的小功能。 比如,寫出這樣的函數(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}
這個函數(shù),是想表達根據(jù)系統(tǒng)是否為MacOS,從而來做不同的事情。從這個函數(shù)可以很容易的看出,其實只有函數(shù)c()是兩種系統(tǒng)共有的,而其它的函數(shù) a(), b(), d(), e()都屬于不同的分支。 但是這種復(fù)用的寫法其實是很不利的。如果一個函數(shù)可能實現(xiàn)2個功能,并且它們之間 共同點少于它們的不同點,那我們最好就寫兩個不同的函數(shù),否則這個函數(shù)的邏輯就不會很清晰,容易出現(xiàn)錯誤。 不要害怕,函數(shù)簡單點不丟人,我們不需要炫技。 好了,根據(jù)上面的說法,這個函數(shù)可以改寫成兩個函數(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ù)不同,也就是說 共同點大于它們的不同點,那就更簡單了,我們可以把相同的部分提取出去,做成一個 輔助函數(shù)。 比如,如果有個函數(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}
然后分別寫兩個函數(shù):
1void funMacOS() { 2 preFun(); 3 d(); 4}
和
1void funOther() { 2 preFun(); 3 e(); 4}
這樣更改之后,是不是清晰了很多,我們既共享了代碼,避免冗余,又做到了每個函數(shù)只做一件簡單的事情。這樣的代碼,邏輯就更加清晰了。
工具函數(shù)
是的,我再說一遍,每個函數(shù)只做一件簡單的事情。但是有些時候在我們的工程代碼中,我們可能會發(fā)現(xiàn)其實里面有很多的重復(fù)。 所以一些常用的代碼,不管它有多短或者多么的簡單,都可以提取出去做成函數(shù),例如有些幫助函數(shù)也許就只有2行,但是我們把它封裝成一個函數(shù)的話,就能大大簡化主要函數(shù)里面的邏輯。 也許你可能會說,這些函數(shù)調(diào)用會增加代碼開銷,但隨著硬件發(fā)展以及技術(shù)變革,這已經(jīng)是一種過時的觀念了。 現(xiàn)代的很多編譯器都能自動的把小的函數(shù) 內(nèi)聯(lián)(inline)到調(diào)用它的地方,所以根本不會產(chǎn)生函數(shù)調(diào)用,也就不會產(chǎn)生任何多余的開銷。 那么我可以使用宏來代替工具函數(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}
同樣,這也許也過時了,我不想讓宏(macro)來背這個鍋,在早期的C語言編譯器里,只有宏是靜態(tài)內(nèi)聯(lián)的,所以使用宏是為了達到內(nèi)聯(lián)的目的。 然而能否內(nèi)聯(lián),其實并不是宏與函數(shù)的根本區(qū)別,這里我不細說了,只要記?。?/span> 應(yīng)該盡量避免使用宏。如果想了解可以參考 避免這7個誤區(qū),才能讓【宏】削鐵如泥 為了內(nèi)聯(lián)而使用宏,其實是濫用了宏,這會引起各種各樣的麻煩,比如使程序難以理解,難以調(diào)試,容易出錯等等。
盡量使用局部變量和參數(shù)
我們應(yīng)該盡量避免使用全局變量和類成員(class member)來傳遞信息,舉個例子: 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(),把一個值寫入成員x。然后,調(diào)用x的值。這樣,x就變成了findX和print之間的數(shù)據(jù)通道。 由于 x屬于class A,這樣程序就失去了模塊化的結(jié)構(gòu),與我們所說的模塊化意義不符了。兩個函數(shù)依賴于成員x,就不再有明確的輸入和輸出,而是依賴全局的數(shù)據(jù)。 函數(shù)findX和fun不再能夠離開 class A而存在,具有依賴性,并且由于類成員還有可能被其他代碼改變,這樣就會導(dǎo)致代碼變得復(fù)雜難以理解,函數(shù)的正確性也難以保證。 如果使用局部變量和參數(shù)來傳遞信息,那么這兩個函數(shù)就不需要依賴于某一個class,不易出錯,代碼如下:
1String findX() { 2 ... 3 x = ...; 4 return x; 5 } 6 void foo() { 7 String x = findX(); 8 print(x); 9 }
總結(jié)
模塊化是指解決一個復(fù)雜問題時,自頂向下,逐層把系統(tǒng)劃分成若干模塊的過程,深入理解模塊化,什么是真正的模塊化,那么我們才能夠事半功倍。 如果你喜歡我的文章表達的思維,轉(zhuǎn)發(fā)分享是對我的厚愛,期待您的點贊在看,下一期,再見!免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!