轉(zhuǎn)自：

組件化開發(fā)和模塊化開發(fā)概念辨析

https://blog.csdn.net/blog_jihq/article/details/79191008

組件饮六、插件辽话、模塊歇终、子應(yīng)用权纤、庫钓简、框架等概念辨析

https://blog.csdn.net/blog_jihq/article/details/80669616

組件化開發(fā)和模塊化開發(fā)概念辨析

網(wǎng)上有許多講組件化開發(fā)、模塊化開發(fā)的文章汹想，但大家一般都是將這兩個概念混為一談的外邓，并沒有加以區(qū)分。而且實際上許多人對于組件古掏、模塊的區(qū)別也不甚明了损话，甚至于許多博客文章專門解說這幾個概念都有些謬誤。

想分清這兩個概念我覺得結(jié)合一下軟件的漸進式開發(fā)場景更容易理解槽唾。但是下面的篇幅會比較長丧枪，所以我先說結(jié)論，不耐煩的同學(xué)可以先看：

概念區(qū)別
對比
類別 目的 特點 接口 成果 架構(gòu)定位
組件 重用庞萍、解耦 高重用拧烦、松耦合 無統(tǒng)一接口 基礎(chǔ)庫、基礎(chǔ)組件 縱向分層
模塊 隔離/封裝 高內(nèi)聚钝计、松耦合 統(tǒng)一接口 業(yè)務(wù)框架恋博、業(yè)務(wù)模塊 橫向分塊
說明
組件：最初的目的是代碼重用，功能相對單一或者獨立私恬。在整個系統(tǒng)的代碼層次上位于最底層交播，被其他代碼所依賴，所以說組件化是縱向分層践付。
模塊：最初的目的是將同一類型的代碼整合在一起秦士，所以模塊的功能相對復(fù)雜，但都同屬于一個業(yè)務(wù)永高。不同模塊之間也會存在依賴關(guān)系隧土，但大部分都是業(yè)務(wù)性的互相跳轉(zhuǎn)，從地位上來說它們都是平級的命爬。
因為從代碼組織層面上來區(qū)分曹傀，組件化開發(fā)是縱向分層，模塊化開發(fā)是橫向分塊饲宛，所以模塊化并沒有要求一定組件化皆愉。也就是說你可以只做模塊化開發(fā)，而不做組件化開發(fā)。那這樣的結(jié)果是什么樣的呢幕庐？就是說你的代碼完全不考慮代碼重用久锥，只是把相同業(yè)務(wù)的代碼做內(nèi)聚整合，不同模塊之間還是存在大量的重復(fù)代碼异剥。這樣的成果也算是做到了模塊化瑟由，只不過我們一般不會這樣而已。

和組件模塊近似的一對概念是庫和框架冤寿。庫的概念偏近于代碼的堆集歹苦，是分層的概念，所以對應(yīng)組件化督怜∨故荩框架是結(jié)構(gòu)化的代碼，所以應(yīng)用于模塊化号杠〕帐框架是骨，模塊化是肉究流。
比如辣吃，ReactiveCocoa是庫，只是提供了響應(yīng)式編碼能力芬探，而基于此的MVVM具體實現(xiàn)成果才叫框架神得，因為框架本身就有架構(gòu)思想在里面。

舉例
下面我們舉例來說明偷仿。
組件化就比如公共的alert框哩簿，最初在許多頁面都有使用，后面提取出一份相同的代碼酝静，其實就是基于代碼復(fù)用的目的节榜。

模塊化就比如一個資訊功能，它本身只在這一個地方使用别智，沒有復(fù)用的需求宗苍，但系統(tǒng)啟動的時候要初始化它的數(shù)據(jù)，首頁顯示的時候要展示它的數(shù)據(jù)薄榛，顯示紅點的時候要拉取它的未讀數(shù)讳窟。這樣一來應(yīng)用中就有很多地方涉及到它的代碼。如果我們將它看做一個整體敞恋，那么資訊模塊和主應(yīng)用的耦合性就非常高了丽啡。所以我們也要把它封裝成模塊，把相關(guān)的代碼放到獨立的單元文件里硬猫，并提供公共方法补箍，這就是高內(nèi)聚的要求改执。

漸進式開發(fā)過程
當(dāng)然這幾個概念在服務(wù)端開發(fā)和客戶端開發(fā)領(lǐng)域有些微差別，我下面的例子就從移動端開發(fā)的角度上進行辨析坑雅。

首先我們定義一個虛擬的產(chǎn)品——一款知識類應(yīng)用辈挂，包含咨詢、問答霞丧、學(xué)院、直播等功能冕香。

接下來我們逐步拆分這個產(chǎn)品蛹尝。

如果開發(fā)時沒有考慮任何組件化模塊化開發(fā)，那么此應(yīng)用的所有功能都是堆積在一起的悉尾，總結(jié)起來就是高耦合突那，低內(nèi)聚，無重用构眯。

1.組件
那么代碼重構(gòu)的第一步是什么呢愕难？
將重復(fù)的代碼合并成為一份，也就是重用惫霸。
我們來看組件化開發(fā)的定義猫缭，它的著重點就是重用，那這一步最后的結(jié)果就是提煉出一個個組件給不同的功能使用壹店。

這里我們可以看一下依賴關(guān)系猜丹，是具體功能依賴提煉出來的組件，組件本身之間可能也有依賴關(guān)系硅卢，但一般不多射窒。所以我們總結(jié)組件化開發(fā)的原則就是高重用，低依賴将塑。當(dāng)然這只是相對而言脉顿。
基于這樣的認(rèn)識，我們甚至于可以把資訊点寥、問答艾疟、學(xué)院、直播等功能封裝成組件敢辩，只不過這些組件比較大汉柒，依賴可能多些，不過本質(zhì)上沒有多少區(qū)別责鳍，而且實際上網(wǎng)上許多文章說所的模塊化開發(fā)其實就是這種組件化的“模塊”碾褂。

2.模塊
下面再說模塊，按照模塊的定義历葛，它是以關(guān)注點進行劃分的正塌，關(guān)注點說到底就是功能嘀略，也就是說根據(jù)我們上面的例子，資訊乓诽、問答帜羊、學(xué)院、直播可以分成不同的模塊鸠天。

我們最開始定義這個虛擬產(chǎn)品的時候說讼育，它有三個特點——高耦合、低內(nèi)聚稠集、無重用奶段。而第一點組件化開發(fā)主要是解決了重用問題，提升了部分內(nèi)聚剥纷，而耦合問題則沒有涉及痹籍。
所以說我們上面可以將這個產(chǎn)品在邏輯上劃分為資訊、問答晦鞋、學(xué)院蹲缠、直播四個模塊，但在代碼層面上它們卻不是四個模塊悠垛，因為它們的代碼都是混雜在一起的线定。比如產(chǎn)品首頁，可能推薦了部分資訊确买、顯示了熱門問答渔肩、推送了目前的直播，而這些功能的代碼則是寫在一起的拇惋；再比如程序啟動的時候周偎，這四個模塊都需要初始化一些數(shù)據(jù)，而初始化數(shù)據(jù)的代碼也是寫在一起的撑帖；再比如程序需要顯示未讀消息數(shù)蓉坎，而這幾個模塊都有自己的未讀消息數(shù)邏輯。
如果未進行模塊化開發(fā)的拆分胡嘿，那么很多時候不同模塊的同一類的代碼都是直接寫在一起的蛉艾，比如系統(tǒng)啟動的時候，我們會在啟動方法里直接寫多個模塊的初始化代碼衷敌。

而模塊化開發(fā)就是為了解決這一問題勿侯，即提高內(nèi)聚，將分屬同一模塊代碼放到一起缴罗；降低耦合助琐，將不同模塊間的耦合程度弱化。
高內(nèi)聚是目標(biāo)面氓，但是現(xiàn)狀是有許多地方會用到多個模塊兵钮，比如啟動的時候會調(diào)用四個模塊蛆橡，首頁會展示三個模塊的界面。如果要高內(nèi)聚掘譬，那么必然需要這些模塊為不同的場景提供相同的方法泰演，這就是說所有模塊要實現(xiàn)同一套多個接口。這樣主應(yīng)用和模塊之間的重耦合就變成了主應(yīng)用和接口耦合葱轩，接口和模塊耦合這樣的松耦合睦焕。
但這樣的簡單模塊只是輕模塊，統(tǒng)一接口較少靴拱。而統(tǒng)一定義的接口越多垃喊，模塊和統(tǒng)一接口的耦合就越高，也便是重模塊缭嫡。

而我們一般講的路由問題其實只是解決模塊間耦合的問題缔御，并不是模塊化開發(fā)的必然需求抬闷，更多時候是基于產(chǎn)品上的動態(tài)化要求妇蛀，只不過我們一般都會在這個時間考慮這一事情而已，就像我們不會只做模塊化開發(fā)同時不做組件化開發(fā)一樣笤成。

講到這里评架，模塊和組件的區(qū)別就已經(jīng)很明顯了。

作者：奇風(fēng)
來源：CSDN
原文：https://blog.csdn.net/blog_jihq/article/details/79191008
版權(quán)聲明：本文為博主原創(chuàng)文章炕泳，轉(zhuǎn)載請附上博文鏈接纵诞！

組件、插件培遵、模塊浙芙、子應(yīng)用、庫籽腕、框架等概念辨析

網(wǎng)上有許多講組件化嗡呼、模塊化等概念的文章，但大家一般都是將這兩個概念混為一談的皇耗，并沒有加以區(qū)分南窗。而且實際上許多人對于組件、插件郎楼、模塊万伤、子應(yīng)用等概念的區(qū)別也不甚明了，甚至于許多博客文章專門解說這幾個概念都有些謬誤呜袁。
之前已經(jīng)寫了一篇文章專門對組件和模塊兩個概念進行辨析敌买，現(xiàn)在我們對于更多的概念在更高的層次上進行辨析。
想分清這幾個概念我覺得結(jié)合一下軟件的漸進式開發(fā)場景更容易理解阶界。但是下面的篇幅會比較長放妈，所以按慣例還是先說結(jié)論北救，不耐煩的同學(xué)可以先看：

1.概念區(qū)別
組件：代碼重用，功能相對單一或者獨立芜抒，無統(tǒng)一接口珍策。組件化開發(fā)的成果是基礎(chǔ)庫和公共組件。
插件：近乎組件宅倒，有統(tǒng)一接口
模塊：高內(nèi)聚攘宙，松耦合，功能相對復(fù)雜拐迁，有多個統(tǒng)一接口蹭劈。模塊化開發(fā)的基礎(chǔ)是框架。
子系統(tǒng)：高于模塊线召，需要生命周期管理铺韧。子系統(tǒng)開發(fā)的基礎(chǔ)是容器。
1.1.組件和插件
插件的概念比較形象缓淹，一般存在一個“插拔”過程哈打，所以要求可插拔的插件有一個相同的接口（這里所說的接口只是概念上的接口，即調(diào)用方法及參數(shù)等）讯壶。而組件是不存在這個相同接口的料仗。
拿我們最常見的網(wǎng)絡(luò)請求功能舉例，無論哪種開發(fā)語言伏蚊，github上可能都有多種網(wǎng)絡(luò)請求組件立轧，那么對于一個項目而言，從一個網(wǎng)絡(luò)組件ComponentA切換為另一個網(wǎng)絡(luò)組件ComponentB是基本無法做到調(diào)用方法不改動的躏吊。
而如果把網(wǎng)絡(luò)請求組件插件化氛改，即在組件外層抽象一層統(tǒng)一化的調(diào)用接口NetworkInterface，然后將當(dāng)前使用網(wǎng)絡(luò)請求組件ComponentA包裝成實現(xiàn)該接口的網(wǎng)絡(luò)請求插件PluginA比伏。那么如果以后需要將使用的ComponentA切換為ComponentB胜卤，那么只需要將ComponentB包裝成PluginB并插入到應(yīng)用中即可。實際調(diào)用時凳怨，業(yè)務(wù)代碼還是調(diào)用NetworkInterface瑰艘，不用做任何修改。
從上面這個例子我們可以看出肤舞，插件和組件的實質(zhì)區(qū)別就在于通過統(tǒng)一接口隔絕業(yè)務(wù)代碼對于組件的直接依賴紫新，這也是我們常聽到的所謂的“項目開發(fā)時應(yīng)該把第三方組件封裝一下再用”。

1.2.組件和模塊
兩者的實質(zhì)區(qū)別在于：組件化開發(fā)是縱向分層李剖，模塊化開發(fā)是橫向分塊芒率。
所以，模塊化并沒有要求一定組件化篙顺，就是說進行模塊化拆分時你可以完全不考慮代碼重用偶芍，只是把同一業(yè)務(wù)的代碼做內(nèi)聚整合成不同的模塊充择。只不過這樣得到的成果相對簡單，我們一般不會這樣而已匪蟀。

組件化就比如項目中公共的alert框椎麦，它的出現(xiàn)其實是基于代碼復(fù)用的目的，所以我們把它封裝材彪，并給多個地方使用观挎。而模塊化就比如一個資訊列表界面，它本身可能只在一個地方使用段化，沒有復(fù)用的需求嘁捷，但我們也要把它封裝成模塊，這是高內(nèi)聚的要求显熏，我們不應(yīng)該把資訊相關(guān)的代碼在項目中放得到處都是雄嚣。
但像這樣的簡單模塊只是輕模塊，統(tǒng)一接口較少喘蟆。而統(tǒng)一定義的接口越多缓升，其實和主應(yīng)用的耦合就越高，也便是重模塊履肃。
而路由就是解決高耦合問題的仔沿，不過耦合問題不是模塊化開發(fā)的需求坐桩，只不過我們一般都會在這個時間考慮這一事情而已尺棋，就像我們不會只做模塊化開發(fā)同時不做組件化開發(fā)一樣。

1.3.模塊和子應(yīng)用
模塊和子應(yīng)用的區(qū)別與組件和插件的區(qū)別有點像绵跷，都在于一個統(tǒng)一接口膘螟。
子應(yīng)用我們不常提，但其實并不少見碾局，像微信小程序荆残，釘釘中的第三方應(yīng)用還有企業(yè)OA應(yīng)用中集成的周邊功能模塊都應(yīng)該屬于子應(yīng)用的概念。
對于模塊而言净当，它暴露給外部調(diào)用的接口一般很少内斯，最常見的就是上面提到的路由規(guī)則，相當(dāng)于可以讓外部通過路由規(guī)則展示它像啼。而子應(yīng)用需要的就不只是一個展示接口俘闯，它可能需要動態(tài)的控制子應(yīng)用的生命周期，以及其他功能上的信息交互（比如忽冻，賬戶信息的同步）真朗，甚至于要做到類似插件那樣的插拔效果。
所以子應(yīng)用必然是接口化的僧诚，而模塊則沒有硬性的要求遮婶。

1.4.庫和框架
除了上面這四種概念蝗碎，還有兩個是我們開發(fā)中常遇到的：庫和框架。
庫旗扑，或者基礎(chǔ)庫蹦骑，概念上偏近于各種工具積累成的集合，是軟件代碼的層面是分層的概念臀防，所以對應(yīng)組件化脊串。基礎(chǔ)庫甚至可以看做是一個大的組件清钥。
而框架顧名思義是結(jié)構(gòu)化的琼锋，是相對整體的一個概念，所以應(yīng)用于模塊化祟昭，甚至是子應(yīng)用化缕坎。
比如在iOS中，RAC是一個庫篡悟，而基于此的一套MVVM的具體實現(xiàn)成果（單頁面的文件結(jié)構(gòu)谜叹，多頁面的交互等等）才叫框架。因為框架本身就有架構(gòu)思想在里面搬葬。

2.漸進式辨析
上面講了一下幾個概念的區(qū)別，當(dāng)然這幾個概念在服務(wù)端開發(fā)和客戶端開發(fā)領(lǐng)域可能有些微差別急凰，我們就不深究了女仰。想要更深入的了解這些概念的區(qū)別，我準(zhǔn)備拿一個漸進式開發(fā)移動端項目的例子進行辨析抡锈。

首先我們定義一個虛擬的產(chǎn)品——一款知識類應(yīng)用疾忍，包含常見的資訊、問答床三、學(xué)院一罩、直播等功能。
接下來我們從設(shè)計的角度逐步拆分這個產(chǎn)品撇簿。

0.原始態(tài)
如果開發(fā)時沒有考慮任何組件化聂渊、模塊化開發(fā)，那么此應(yīng)用的所有功能都是堆積在一起的四瘫，總結(jié)起來就是代碼特點就是高耦合汉嗽，低內(nèi)聚，無重用莲组。
面對這樣的一堆代碼诊胞，技術(shù)經(jīng)理可能要讓你做一下代碼重構(gòu)，這就是你下一步的工作。

1.組件
那么你進行代碼重構(gòu)的第一步是什么呢撵孤？
答：將工程中重復(fù)的代碼合并成為一份迈着，也就是重用。

如果讓我們來看組件化開發(fā)的定義邪码，它的著重點就是代碼重用裕菠。那這一步最后的結(jié)果就是提煉出一個個組件給不同的功能使用。
這里我們可以看一下其中的依賴關(guān)系：具體功能依賴提煉出來的組件闭专，組件本身之間可能也有依賴關(guān)系奴潘，但一般不多。所以我們總結(jié)組件化開發(fā)的原則就是高重用影钉，低耦合画髓。當(dāng)然這只是相對而言。

基于這樣的認(rèn)識平委，我們甚至于可以把資訊奈虾、問答、學(xué)院廉赔、直播等功能封裝成組件肉微，只不過這些組件比較大，依賴可能多些蜡塌，不過本質(zhì)上沒有多少區(qū)別碉纳。
就在你進行重構(gòu)的過程中，這時需求來了：運營人員要求首頁頂部的九宮格樣式工具欄可動態(tài)配置馏艾，通過服務(wù)端數(shù)據(jù)修改顯示功能劳曹，并調(diào)用對應(yīng)的功能頁面。

2.插件
代碼重構(gòu)從來不是超然物外的攒至，在進行過程中接到新需求也是常有的事情厚者。那么躁劣，對于這樣一個需求迫吐，應(yīng)該怎么考慮呢？
這個動態(tài)化需求很普遍账忘，只不過這里有一個隱性要求——既然需求中要求功能動態(tài)配置志膀，那么調(diào)用功能的地方就不知道功能的具體實現(xiàn)。

所以最終的方案中被調(diào)用功能必須有統(tǒng)一接口鳖擒。我們這里說的接口只是編程領(lǐng)域的抽象概念溉浙，并非是指具體語言的interface或者protocol。

而有了這一統(tǒng)一接口蒋荚，其配置功能其實就是“插拔”過程了戳稽。這樣的成果實質(zhì)上已經(jīng)是插件了。
插件可以解釋成可插拔式組件，它的核心就是不同功能實現(xiàn)提供統(tǒng)一接口惊奇。
項目中插件化的例子其實也不少互躬，再舉一個例子：比如資訊和問答功能使用的彈框樣式不同，但是在兩個功能內(nèi)部其彈框樣式是一致的颂郎。
面對這樣的問題吼渡，你在重構(gòu)時可能會簡單的封裝出兩個組件AlertA和AlertB，分別給兩個功能使用乓序。這樣確實很便捷寺酪，而且適合當(dāng)下的場景，但是從設(shè)計或者長遠發(fā)展的角度上來考慮替劈，如果資訊里面彈框樣式需要換成和問答一樣寄雀，甚至其他樣式，那么基于現(xiàn)有的方法陨献，你就需要修改資訊功能中所有調(diào)用彈框的地方餐济。
所以插件化是解決這個問題的好辦法：定義AlertInterface接口給具體業(yè)務(wù)功能使用焕窝，并實現(xiàn)AlertPluginA、AlertPluginB，在外面給不同的功能指定不能的插件即可秧廉。

3.模塊
這時候項目的組件化拆分完成，技術(shù)經(jīng)理說以后不同的模塊會交由不同的人來維護小槐，各人維護各自負責(zé)的代碼污秆。
這個需求初看上去只是項目管理上的需求，但實際執(zhí)行時若資訊墅茉、問答命黔、學(xué)院、直播分別由四個人維護就斤，那么他們雖然大部分代碼是相互隔離的悍募，但仍然會有相當(dāng)一部分代碼耦合在一起，有時候會同時修改同一個代碼文件洋机。
這時候要做的自然就是模塊化坠宴。
為什么是模塊化呢？按照模塊的定義绷旗，它是以關(guān)注點進行劃分的喜鼓，而關(guān)注點說到底就是功能，也就是說根據(jù)我們上面的例子衔肢，資訊庄岖、問答、學(xué)院角骤、直播可以分成不同的模塊隅忿。

我們最開始定義這個虛擬產(chǎn)品的時候說，它有三個特點——高耦合、低內(nèi)聚背桐、無重用刘陶。而第一點組件化開發(fā)主要是解決了重用問題，提升了部分內(nèi)聚牢撼，而耦合問題則沒有涉及匙隔。
所以說我們上面可以將這個產(chǎn)品在邏輯上劃分為資訊、問答熏版、學(xué)院纷责、直播四個模塊，但在代碼層面上它們卻不是四個模塊撼短，因為它們的代碼都是混雜在一起的再膳。比如產(chǎn)品首頁，可能推薦了部分資訊曲横、顯示了熱門問答喂柒、推送了目前的直播，而這些功能的代碼則是寫在一起的禾嫉；再比如程序啟動的時候灾杰，這四個模塊都需要初始化一些數(shù)據(jù)，而初始化數(shù)據(jù)的代碼也是寫在一起的熙参。

而模塊化開發(fā)就是為了解決這一問題艳吠，即提高內(nèi)聚，將分屬同一模塊代碼放到一起孽椰；降低耦合昭娩，將不同模塊間的耦合程度弱化。
高內(nèi)聚是這一步的目標(biāo)黍匾。但現(xiàn)狀是有許多地方會用到多個模塊栏渺，比如啟動的時候會調(diào)用四個模塊，首頁會展示三個模塊的界面锐涯。如果要高內(nèi)聚磕诊，那么必然需要這些模塊為不同的場景提供相同的方法，這就是說所有模塊要實現(xiàn)同一套多個接口全庸。
而低耦合其實并非是模塊化開發(fā)的要求秀仲，其實更多時候是基于產(chǎn)品上的動態(tài)化要求，所以最常見的解決方案就是路由機制壶笼。

講到這里，我們可以看到模塊化和組件化的區(qū)別就已經(jīng)很明顯了雁刷。
對于一般應(yīng)用而言覆劈，代碼設(shè)計優(yōu)化到這一步就很好了，無論是代碼可讀性、可維護性责语、工作協(xié)作效率都得到了保障炮障。不過為了講到我們上面所說的所有概念，我們不妨皮一下坤候，給自己提點需求：
產(chǎn)品經(jīng)理想把學(xué)院模塊單獨提出來做一個APP胁赢，但是因為技術(shù)經(jīng)理反映開發(fā)資源有限，不能給這個APP配備獨立的開發(fā)人員白筹，所以最終的結(jié)果是這個APP的功能和原應(yīng)用中的學(xué)院模塊使用同一套代碼智末，且功能相同。

4.子應(yīng)用
對于開發(fā)人員來說徒河，這也不能算多困難的需求系馆，只需要再創(chuàng)建一個新工程，將學(xué)院模塊代碼引用過來并顯示即可顽照。
這個方案簡單直接由蘑，即便后面再把直播分離出單獨APP我也可以這樣來做。
但是代兵，有沒有覺得這個方案和我們之前提到的Alert的例子有些神似尼酿，在這個方案中，新的工程必然直接耦合具體的模塊代碼植影，你需要在里面編寫很多初始化代碼谓媒。而這樣的代碼在單獨的APP中和原APP中是相當(dāng)類似的。
按照《重構(gòu)》一書中的提法何乎，這是明顯的壞味道句惯，我們應(yīng)該在工程和模塊代碼之間抽象出一層接口，使兩者解除直接耦合支救，這樣我們甚至可以做到只需要配置就可以將一個模塊變成一個新的APP抢野。
(或許在這個例子中，有些過度設(shè)計了各墨，但是原諒我舉不出更合情理的例子TAT)

上面方案的成果指孤，實際上就把學(xué)院模塊編程了學(xué)院子應(yīng)用，而這個子應(yīng)用被原APP和新的獨立APP所使用贬堵。
在概念上恃轩，子應(yīng)用比模塊的范圍更大，子應(yīng)用要求能在主應(yīng)用里運行黎做，也要求必要時可以自己運行叉跛，那么就必然要求子應(yīng)用要提供生命周期接口，和主應(yīng)用必要時保持一致蒸殿。

其實在上面一步的模塊化開發(fā)中筷厘，有的時候也會有生命周期接口的要求鸣峭，只不過并非強制，而子應(yīng)用的設(shè)計中則是必須要考慮的酥艳。

3.總結(jié)
到此摊溶，我們就把組件、插件充石、模塊莫换、子應(yīng)用四個不同程度的設(shè)計概念異同講完了，希望讀者能有所得骤铃。文章中若有其他不足之處拉岁，懇請不吝賜教。

作者：奇風(fēng)
來源：CSDN
原文：https://blog.csdn.net/blog_jihq/article/details/80669616
版權(quán)聲明：本文為博主原創(chuàng)文章劲厌，轉(zhuǎn)載請附上博文鏈接膛薛！