元件化開發和模組化開發概念辨析
網上有許多講元件化開發、模組化開發的文章,但大家一般都是將這兩個概念混為一談的,並沒有加以區分。而且實際上許多人對於元件、模組的區別也不甚明瞭,甚至於許多部落格文章專門解說這幾個概念都有些謬誤。
想分清這兩個概念我覺得結合一下軟體的漸進式開發場景更容易理解。但是下面的篇幅會比較長,所以我先說結論,不耐煩的同學可以先看:
概念區別
對比
說明
l 元件:最初的目的是程式碼重用,功能相對單一或者獨立。在整個系統的程式碼層次上位於最底層,被其他程式碼所依賴,所以說元件化是縱向分層。
l 模組:最初的目的是將同一型別的程式碼整合在一起,所以模組的功能相對複雜,但都同屬於一個業務。不同模組之間也會存在依賴關係,但大部分都是業務性的互相跳轉,從地位上來說它們都是平級的。
因為從程式碼組織層面上來區分,元件化開發是縱向分層,模組化開發是橫向分塊,所以模組化並沒有要求一定元件化。也就是說你可以只做模組化開發,而不做元件化開發。那這樣的結果是什麼樣的呢?就是說你的程式碼完全不考慮程式碼重用,只是把相同業務的程式碼做內聚整合,不同模組之間還是存在大量的重複程式碼。這樣的成果也算是做到了模組化,只不過我們一般不會這樣而已。
和元件模組近似的一對概念是庫和框架。庫的概念偏近於程式碼的堆集,是分層的概念,所以對應元件化。框架是結構化的程式碼,所以應用於模組化。框架是骨,模組化是肉。
講到這給大家介紹一個快速開發平臺:力軟快速開發平臺(配置型快速開發平臺,內含代 碼生成器、工作流、APP開發、移動端等多種功能)
舉例
下面我們舉例來說明。
元件化就比如公共的alert框,最初在許多頁面都有使用,後面提取出一份相同的程式碼,其實就是基於程式碼複用的目的。
模組化就比如一個資訊功能,它本身只在這一個地方使用,沒有複用的需求,但系統啟動的時候要初始化它的資料,首頁顯示的時候要展示它的資料,顯示紅點的時候要拉取它的未讀數。這樣一來應用中就有很多地方涉及到它的程式碼。如果我們將它看做一個整體,那麼資訊模組和主應用的耦合性就非常高了。所以我們也要把它封裝成模組,把相關的程式碼放到獨立的單元檔案裡,並提供公共方法,這就是高內聚的要求。
漸進式開發過程
當然這幾個概念在服務端開發和客戶端開發領域有些微差別,我下面的例子就從移動端開發的角度上進行辨析。
首先我們定義一個虛擬的產品——一款知識類應用,包含諮詢、問答、學院、直播等功能。
接下來我們逐步拆分這個產品。
如果開發時沒有考慮任何元件化模組化開發,那麼此應用的所有功能都是堆積在一起的,總結起來就是高耦合,低內聚,無重用。
1.元件
那麼程式碼重構的第一步是什麼呢?
將重複的程式碼合併成為一份,也就是重用。
我們來看元件化開發的定義,它的著重點就是重用,那這一步最後的結果就是提煉出一個個元件給不同的功能使用。
這裡我們可以看一下依賴關係,是具體功能依賴提煉出來的元件,元件本身之間可能也有依賴關係,但一般不多。所以我們總結元件化開發的原則就是高重用,低依賴。當然這只是相對而言。
基於這樣的認識,我們甚至於可以把資訊、問答、學院、直播等功能封裝成元件,只不過這些元件比較大,依賴可能多些,不過本質上沒有多少區別,而且實際上網上許多文章說所的模組化開發其實就是這種元件化的“模組”。
2.模組
下面再說模組,按照模組的定義,它是以關注點進行劃分的,關注點說到底就是功能,也就是說根據我們上面的例子,資訊、問答、學院、直播可以分成不同的模組。
我們最開始定義這個虛擬產品的時候說,它有三個特點——高耦合、低內聚、無重用。而第一點元件化開發主要是解決了重用問題,提升了部分內聚,而耦合問題則沒有涉及。
所以說我們上面可以將這個產品在邏輯上劃分為資訊、問答、學院、直播四個模組,但在程式碼層面上它們卻不是四個模組,因為它們的程式碼都是混雜在一起的。比如產品首頁,可能推薦了部分資訊、顯示了熱門問答、推送了目前的直播,而這些功能的程式碼則是寫在一起的;再比如程式啟動的時候,這四個模組都需要初始化一些資料,而初始化資料的程式碼也是寫在一起的;再比如程式需要顯示未讀訊息數,而這幾個模組都有自己的未讀訊息數邏輯。
如果未進行模組化開發的拆分,那麼很多時候不同模組的同一類的程式碼都是直接寫在一起的,比如系統啟動的時候,我們會在啟動方法裡直接寫多個模組的初始化程式碼。
而模組化開發就是為了解決這一問題,即提高內聚,將分屬同一模組程式碼放到一起;降低耦合,將不同模組間的耦合程度弱化。
高內聚是目標,但是現狀是有許多地方會用到多個模組,比如啟動的時候會呼叫四個模組,首頁會展示三個模組的介面。如果要高內聚,那麼必然需要這些模組為不同的場景提供相同的方法,這就是說所有模組要實現同一套多個介面。這樣主應用和模組之間的重耦合就變成了主應用和介面耦合,介面和模組耦合這樣的松耦合。
但這樣的簡單模組只是輕模組,統一介面較少。而統一定義的介面越多,模組和統一介面的耦合就越高,也便是重模組。
而我們一般講的路由問題其實只是解決模組間耦合的問題,並不是模組化開發的必然需求,更多時候是基於產品上的動態化要求,只不過我們一般都會在這個時間考慮這一事情而已,就像我們不會只做模組化開發同時不做元件化開發一樣。
講到這裡,模組和元件的區別就已經很明顯了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31428300/viewspace-2671805/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 模組化開發(二)
- 前端模組化開發前端
- webpack+jquery 元件化、模組化開發的解決方案WebjQuery元件化
- 聊聊前端模組化開發前端
- 淺談模組化開發
- 模組化開發淺析
- Js模組化開發的理解JS
- Android模組化開發實踐Android
- Javascript模組化開發基礎JavaScript
- Android元件化開發案例(融合數10個專案模組)Android元件化
- springboot模組化開發專案搭建Spring Boot
- php+mysql+cookie+模組化開發PHPMySqlCookie
- Vue 元件化開發Vue元件化
- Vue元件化開發Vue元件化
- 元件化開發(二)元件化
- duxapp:基於Taro使用模組化開發,提升開發效率UXAPP
- 前端為什麼需要模組化開發前端
- 視覺化佈局模組開發分享視覺化
- 為什麼JavaScript需要模組化開發?JavaScript
- 工程化、模組化、元件化 開發工作中這三項有什麼區別元件化
- 程式模組化設計結構化開發優勢
- 什麼是前端模組化?前端模組化開發到底有無必要前端
- 元件化開發與黑箱元件化
- Flutter元件化開發方案Flutter元件化
- iOS的元件化開發iOS元件化
- 元件化開發的思考元件化
- 聊聊MVC和模組化以及MVVM和元件化MVCMVVM元件化
- 模組化開發靜態資源對映
- Laravel RESTFul API 模組化開發解決方案LaravelRESTAPI
- 基於Laravel5.5的模組化開發Laravel
- 微信小遊戲開發(8)-模組化遊戲開發
- 資料視覺化之模組邊框繪製,以及元件開發(一)視覺化元件
- Android元件化開發實踐和案例分享Android元件化
- Android元件化開發實踐(一):為什麼要進行元件化開發?Android元件化
- 前端開發之ES6模組化和node.js,2020.12.09前端Node.js
- Flutter元件化混合開發-AndroidFlutter元件化Android
- Vue 元件化開發之插槽Vue元件化
- Dapr和Rainbond整合,實現雲原生BaaS和模組化微服務開發AI微服務