1.模塊（Model）

通常所指“模塊”是指編程語言所提供的代碼組織機制，利用此機制可將程序拆解為獨立且通用的代碼單元。

根據不同的關注點，將一個項目的可以共享的部分抽取出來，形成獨立的Module，就是模塊化。

對于JavaScript來說，在ES6之前，并沒有語言內置的模塊機制，但我們用一些方式自制了某種模塊機制，像CommonJS / AMD甚至建立了普遍接受的社區標準。雖然它們都是模塊機制，但會有一些重大或微妙的差異。故當我們提到JS模塊時，如果沒有足夠的上下文，有時需要明確是CommonJS module或AMD module或ES6 module。

對于CSS來說，并沒有普遍接受的“CSS模塊”概念。一個CSS樣式表里可以通過@import來引入其他樣式表，但我們通常并不稱之為“模塊”。多份樣式表以cascade機制結合，這和我們一般編程語言中模塊互相調用的方式相當不同。且CSS的@import語義基本上就是最簡單的include，也就是將@import語句替換為導入樣式表的內容。而編程語言中的導入模塊會在當前作用域導入命名空間、符號等，比簡單的include要復雜許多。

有關“CSS模塊”的問題，我們后面還會討論。

注：在Web標準中，“CSS module”其實指CSS spec本身的模塊化。這也是我們應該避免采用“CSS模塊”來指代CSS代碼的組織結構的重要原因。

其實我公司里對“模塊”的用法也比較隨便。比如我們有/static/js/modules/目錄，其實下面就是一些腳本，并沒有采用任何一種module規范。再如我們有/src/modules/目錄，下面每個子目錄是業務模塊，里面包含了view、controller和相關的各種類。

這里一個是歷史因素——目錄結構不是我建立的，大家習慣如此，都知道我們講的“module”是指業務模塊，跟具體編程語言里的module沒有直接的關系，只要溝通沒有什么障礙，那也不必改了。不過當我們完成引入JS module loader和相關設施之后，很可能還是需要重新調整文檔和目錄命名，以避免可能的理解錯位。

回到關于“模塊”的定義討論上，我建議運用此術語時盡量避免擴張性解釋——即避免在脫離特定機制的general的“模塊化”的意義上使用“模塊”這個詞。

比如，傳統的JS代碼組織方法之一，是掛在global上的層級命名空間。此嚴格上不好稱之為“模塊”。原因是namespace只提供邏輯劃分，不解決代碼本身的劃分。如果沒有其他機制，代碼劃分仍然是文件為單位，并由開發者自己指定script加載。同理，我們通常認為C++里沒有模塊（盡管有namespace和include），但是PHP我們認為有模塊（因為它有autoloader可以根據namespace映射到目錄去加載文件）。

當然，即便編程語言沒有模塊，我們仍然可以通過一些方式進行“模塊化”編程，但這種模糊的用法有可能造成誤解。在JS這邊因為我們已經有很成熟的CommonJS / AMD / ES6 module了，更應避免模糊用法。

2.組建（component）

另一個概念是“組件”。大體上“組件”和“模塊”的概念是類似的，只是“組件”通常指更high-level的東西。

我個人體會，“模塊”指代碼單元，其意義偏向靜態的代碼結構。而“組件”指功能單元，其意義偏向運行時的結構，并有更復雜的控制（如組件實例的生命周期管理）。

舉例來說，在組件系統中，你應該可以比較容易的做到在運行時查找某種組件并替換為另一種組件（熱插拔）。而這通常并不作為模塊系統的需求——即使模塊系統支持動態加載，通常也不支持注銷舊模塊；即使支持注銷舊模塊，通常也不支持替換所有舊模塊的引用（意味著需要重新 實例化/初始化 模塊依賴樹上所有直接或間接引用此模塊的模塊）。

注：的確有某Node.js平臺下的游戲框架設計以class作為模塊單元，通過替換prototype來做到模塊的熱插拔。不過這其實要求非常多的編程方式約定，實際上可被視為使用的是JS的一個裁剪的特性子集，因而不具有普遍性。

轉載于:https://www.cnblogs.com/Alice-67/p/10896128.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的模块的概念，组建地概念？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。