模組化是為了減少系統耦合度，提高系統可用性，也就是大家平時說的高內聚，低耦合。

首先說下模組化的優點:

1. 模組化方便開發者維護，同樣的程式碼邏輯複用，最簡單的就是函式封裝，接入層，邏輯層分離。

2. 減少依賴，系統模組化，改動新功能的時候開發量會小很多。

3. 方便管理

是的，模組化的目的在於將一個程式按照其功能做拆分，分成相互獨立的模組，以便於每個模組只包含與其功能相關的內容，模組之間透過介面呼叫。將一個大的系統模組化之後，每個模組都可以被高度複用。

1.什麼是模組化？

模組化是為了減少系統耦合度，提高內聚，減少資源迴圈依賴，增強系統框架設計。

模組化便於開發者維護，同時也讓邏輯相同的部分可複用。

模組化開發，以功能或業務為單元組織程式碼。

2.模組化的優點

模組化不只提高了程式碼的複用度，還可以實現真正的功能複用，比如同樣的功能模組如果實現了自完備性，可以在多個專案中複用。

模組化對程式碼的封裝性、合理性都有要求，進而可以實現業務隔離，以及跨團隊開發程式碼控制和版本風險控制。

3.模組化的基本原則

單一職責，意味著一個模組、一個元件只做一件事，絕不多做。開放-封閉原則，是說模組應該可以擴充套件，但是不可以修改。依賴倒轉原則，即高層模組不應該依賴底層模組，兩個都應該依賴於抽象；抽象不應該依賴細節，細節應該依賴抽象。緊湊性，模組、元件對外暴露的介面、屬性應該儘可能的少，介面的引數個數也要少。面向介面，模組、元件對外提供服務時最好是面向介面的，以便後期可以靈活的變更實現。

4.模組化的缺點

任何事物當然有優點就會有缺點，模組化對於新手來說需要時間成本，團隊間的配合也需要磨合期，因此開發效率在初期會降低。但是模組化的好處遠遠大於這些缺點，因此模組化仍然是很好的架構選擇。

模組化程式設計是將計算機程式細分為單獨的子程式的過程。模組是一個單獨的軟體元件，它通常可以與系統的其他元件一起用於各種應用程式和功能。

模組化程式設計背景一些程式可能具有數千行或數百萬行，並且要管理此類程式變得非常困難，因為程式中可能存在太多語法錯誤或邏輯錯誤，因此要管理這種型別的程式，需要採用模組化程式設計的概念。每個子模組僅包含所需功能的一個方面，模組化程式設計強調將大型程式分解為小問題，以提高程式碼的可維護性，可讀性，並使程式便於將來進行任何更改或更正錯誤。模組化程式設計優勢

易用性

這種方法可簡化操作，因為我們可以一次以模組的形式訪問它，而不是一次關注整個數千萬行程式碼。這樣可以輕鬆除錯程式碼，並減少錯誤。

可重用性

它允許使用者透過其他介面重用功能，而無需再次鍵入整個程式。

易於維護

在處理模組時，它有助於減少衝突，幫助團隊在處理大型應用程式時進行適當的協作。

C語言中的模組化程式設計示例

C之所以稱為結構化程式語言，是因為為了解決一個大問題，C程式語言將問題分為稱為功能或過程的較小模組，每個模組負責特定的職責，解決整個問題的程式就是這些功能的集合。

模組基本上是一組相互關聯的檔案，它們共享其實現細節，但對外界隱藏。我們如何在c中實現模組化程式設計？預設情況下，在C中定義的每個函式都可以全域性訪問。這可以透過包括在其中定義函式實現的標頭檔案來完成。

假設我們要宣告一個堆疊資料型別，同時要向用戶隱藏實現（包括其資料結構）。為此，我們首先定義一個名為stack.h的公共檔案，該檔案包含通用資料Stack資料型別和該堆疊資料型別支援的功能。

在標頭檔案中，我們必須僅使用模組名稱來包含常量，結構，變數和函式的定義，這樣可以輕鬆地在具有多個模組的較大程式中識別定義源。

關鍵字extern和static幫助實現C中的模組化。

現在我們可以建立一個名為stack.c的檔案，其中包含堆疊資料型別的實現：

主檔案可能包括模組堆疊

哲學的思考

程式碼是為了解決現實世界問題的，同樣他也可以在一定程度上去反應現實世界的狀態，我們在現實世界中的經驗也可以在程式碼開發的過程中進行借鑑。接下來，我們看一下現實世界中關於模組化有哪些應用。

現實世界

現實中有很多模組化應用的場景，比如：衣服的拉鍊是一個模組，手錶及錶鏈是相互配合的兩個模組，電腦由也是由多個不同模組組成，具體如下：

電腦由CPU，顯示卡，記憶體，硬碟，鍵盤，螢幕，滑鼠等待標準模組組成。那麼，電腦的模組化有什麼好處呢？

對於消費方的我們可以按照自己的喜好及需要去進行組合，或者針對某一個模組去升級。對於生產方的廠商，他們可以按照標準介面，去分別實現自己的模組。迴歸到程式碼的模組化

1. 程式碼層面

程式碼的模組化，可以方便程式碼進行復用，一套邏輯寫一遍即可。

2. 業務層面

程式碼的模組化：靜態思考

降低複雜度，便於組合：將系統拆分成一個個小的模組，每一個模組所需關注的業務及邏輯減少，實現起來更加簡單；同時，利用這些模組，可以方便進行各種各樣的組合，可以應對各種各樣的需求。

程式碼的模組化：動態思考

隨著業務的演進，需求不斷變化，會產生兩種變化：針對某個模組的邏輯變化：此時只需要修改對應的模組內部邏輯即可，其它模組無感知；針對模組的組合發生變化：此時只需要修改模組組合處即可，模組內部無感知。當然，以上兩種情況，也可能同時出現，分別做相應的修改即可。

程式碼的模組化：專案的長期可維護性思考

一套程式碼經歷幾年的生命之後，同樣也會經歷多個開發者修改或者新增邏輯，甚至整個開發團隊都有可能發生變化。這個時候的程式碼，往往會腐化，邏輯纏繞，引用關係複雜，程式碼冗長，為了補坑的打的補丁式程式碼隨處可見。

如果這個專案還需要繼續，那麼不得不進行重構，或者重新開發，但是我們如果針對整個專案進行重構，風險太大，往往進行小步快走，按模組進行重構，那麼這種方式得以實現的前提是，前期做好了模組化拆分。

3. 人員的組織架構方面

進行模組化拆分之後，我們可以針對不同的模組進行並行推動，進而縮短專案整體的完成時間，主要可以並行的有：產品設計可以並行，開發可以並行，測試可以並行。

任何事情的好壞，都是相對而言的！

模組化和非模組化在一般情況下對比，複用和管理的優點還是比較明顯的！

對比：

1 當專案非常小的時候（小外掛），不會有太大的改動，也就沒有必要模組化了，

過度追求模組化，可能讓你的程式碼量更多

2 當專案較為複雜的時候，經常會存在各個模組之間的呼叫，如果模組化程度過低，

則會導致，你修改其中很小的一部分，都要考慮對整個專案的影響，風險高且效率低