一 iOS MVC、MVVM、MVP
1 MVC
MVC是80年代出現(xiàn)的一種軟件設(shè)計(jì)模式，是模型（model），視圖（view）和控制（Controller）的縮寫。
? ? 其中Model的主要功能包括業(yè)務(wù)邏輯的處理以及數(shù)據(jù)的訪問(wèn)，這是應(yīng)用程序的主體部分。
? ? View的主要功能是用來(lái)跟用戶進(jìn)行交互，實(shí)現(xiàn)數(shù)據(jù)的收集和展示，視圖是用戶看到和直接操作的的界面，它只接受用戶的操作。
? ? ?Controller的主要功能用來(lái)在視圖和模型之間建立聯(lián)系并控制數(shù)據(jù)的走向，控制器本身不輸出任何內(nèi)容和對(duì)數(shù)據(jù)做任何處理。
一個(gè)簡(jiǎn)單的計(jì)算器，它除了我們一貫看到的輸入輸出界面，其實(shí)它的內(nèi)部還有負(fù)責(zé)運(yùn)算的模塊和負(fù)責(zé)控制的部件
Controller根據(jù)用戶在View上的操作，將輸入的數(shù)字傳給Model，model保存數(shù)字并根據(jù)要求進(jìn)行加減乘除，進(jìn)行數(shù)據(jù)分析，再將得到的結(jié)果傳給Controllr，由Controller把結(jié)果交給View，View把結(jié)果顯示出來(lái)。
缺點(diǎn):
愈發(fā)笨重的 Controller;
太過(guò)于輕量級(jí)的 Model：
遺失的網(wǎng)絡(luò)邏輯;
較差的可測(cè)試性;
2 MVVM
從字面意思來(lái)理解，MVVM 即 Model View ViewModel（模型 視圖 視圖模型）。MVC 是一個(gè)用來(lái)組織代碼的權(quán)威范式，也是構(gòu)建 iOS App 的標(biāo)準(zhǔn)模式。Apple 甚至是這么說(shuō)的。在 MVC 下，所有的對(duì)象被歸類為一個(gè) model，一個(gè) view，或一個(gè) controller。Model 持有數(shù)據(jù)，View 顯示與用戶交互的界面，而 View Controller 調(diào)解 Model 和 View 之間的交互。然而，隨著模塊的迭代我們?cè)絹?lái)越發(fā)現(xiàn) MVC 自身存在著很多不足。因此，MVVM 從其他應(yīng)用而出，在 iOS 中從此我們完全將業(yè)務(wù)邏輯加以區(qū)分并使用這套思想。在 MVVM 中他的設(shè)計(jì)思路和 MVC 很像。它正式規(guī)范了視圖和控制器緊耦合的性質(zhì)，并引入新的組件 ViewModel。此外，它還有像監(jiān)管版本的 MVP 那樣的綁定功能，但這個(gè)綁定不是在 View 和 Model 之間而是在 View 和 ViewModel 之間。
1）MVVM 模式下的三個(gè)特性的分析：
任務(wù)均攤 -- MVVM 的 View 要比 MVP 中的 View 承擔(dān)的責(zé)任多。因?yàn)榍罢咄ㄟ^(guò) ViewModel 的設(shè)置綁定來(lái)更新?tīng)顟B(tài)，而后者只監(jiān)聽(tīng) Presenter 的事件但并不會(huì)對(duì)自己有什么更新。
可測(cè)試性 -- ViewModel 不知道關(guān)于 View 的任何事情，這允許我們可以輕易的測(cè)試 ViewModel。同時(shí) View 也可以被測(cè)試，但是由于屬于 UIKit 的范疇，對(duì)他們的測(cè)試通常會(huì)被忽略。
易用性 -- 在實(shí)際開(kāi)發(fā)中必須把 View 中的事件指向 Presenter 并且手動(dòng)的來(lái)更新 View，如果使用綁定的話，MVVM 代碼量將會(huì)小的多。
作者：9歲就很6
鏈接：http://www.itdecent.cn/p/d39a5eee48d7
來(lái)源：簡(jiǎn)書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
3 MVP
從字面意思來(lái)理解，MVP即Model View Presenter（模型 視圖 協(xié)調(diào)器），MVP實(shí)現(xiàn)了Cocoa的MVC的愿景。MVP的協(xié)調(diào)器Presenter并沒(méi)有對(duì)ViewController的聲明周期做任何改變，因此View可以很容易的被模擬出來(lái)。在Presenter中根本沒(méi)有和布局有關(guān)的代碼，但是它卻負(fù)責(zé)更新View的數(shù)據(jù)和狀態(tài)。
MVP 是第一個(gè)如何協(xié)調(diào)整合三個(gè)實(shí)際上分離的層次的架構(gòu)模式，既然我們不希望 View 涉及到 Model，那么在顯示的 View Controller（其實(shí)就是 View）中處理這種協(xié)調(diào)的邏輯就是不正確的，因此我們需要在其他地方來(lái)做這些事情。例如，我們可以做基于整個(gè) App 范圍內(nèi)的路由服務(wù)，由它來(lái)負(fù)責(zé)執(zhí)行協(xié)調(diào)任務(wù)，以及 View 到 View 的展示。這個(gè)出現(xiàn)并且必須處理的問(wèn)題不僅僅是在 MVP 模式中，同時(shí)也存在于以下集中方案中。
MVC和MVP的區(qū)別就是，在MVP中M和V沒(méi)有直接通信。
1）MVP模式下的三個(gè)特性的分析：
任務(wù)均攤 -- 我們將最主要的任務(wù)劃分到 Presenter 和 Model，而 View 的功能較少；
可測(cè)試性 -- 非常好，由于一個(gè)功能簡(jiǎn)單的 View 層，所以測(cè)試大多數(shù)業(yè)務(wù)邏輯也變得簡(jiǎn)單；
易用性 -- 代碼量比 MVC 模式的大，但同時(shí) MVP 的概念卻非常清晰。
參考：iOS MVC、MVVM、MVP詳解 - 簡(jiǎn)書
工廠模式
簡(jiǎn)單工廠模式VS. 工廠模式
簡(jiǎn)單工廠模式的最大優(yōu)點(diǎn)在于工廠類中包含了必要的邏輯判斷， 根據(jù)客戶端的選擇條件動(dòng)態(tài)實(shí)例化相關(guān)的類， 對(duì)于客戶端來(lái)說(shuō)，去除了具體產(chǎn)品的依賴
工廠方法模式是現(xiàn)實(shí)， 客戶端需要決定實(shí)例化哪一個(gè)工廠來(lái)實(shí)現(xiàn)運(yùn)算類，選在判斷的問(wèn)題還是存在的， 也就是說(shuō)， 工廠方法吧簡(jiǎn)單的工廠的內(nèi)部邏輯判斷移到了客戶端代碼來(lái)進(jìn)行， 想要加功能， 搬來(lái)是修稿工廠類的， 而現(xiàn)在修改的是客戶端
工廠模式 相比簡(jiǎn)單工廠模式 更具有低耦合，可擴(kuò)展性強(qiáng)。工廠模式保持了簡(jiǎn)單工廠模式的有點(diǎn)，并且克服了它的缺點(diǎn)， 但工廠模式的缺點(diǎn)是魷魚每增加一個(gè)產(chǎn)品， 就需要增加一個(gè)產(chǎn)品工廠的類， 總價(jià)了額外的開(kāi)發(fā)量
為什么使用工廠模式?
在程序開(kāi)發(fā)中,有時(shí)候我們不得不根據(jù)不同的場(chǎng)景,去創(chuàng)建不同的實(shí)體類,利用此種模式,我們可以充分的規(guī)劃我們的代碼,使得項(xiàng)目的層級(jí)結(jié)構(gòu)更加清晰,在什么樣的場(chǎng)景下,使用什么樣的實(shí)體
注意事項(xiàng)：作為一種創(chuàng)建類模式，在任何需要生成復(fù)雜對(duì)象的地方，都可以使用工廠方法模式。有一點(diǎn)需要注意的地方就是復(fù)雜對(duì)象適合使用工廠模式，而簡(jiǎn)單對(duì)象，特別是只需要通過(guò) new 就可以完成創(chuàng)建的對(duì)象，無(wú)需使用工廠模式。如果使用工廠模式，就需要引入一個(gè)工廠類，會(huì)增加系統(tǒng)的復(fù)雜度。(簡(jiǎn)單來(lái)說(shuō):不要刻意的為了使用工廠模式,而去使用工廠模式開(kāi)發(fā),使用工廠模式,僅僅是為了讓代碼邏輯根據(jù)清晰,如果完全可以 alloc 的事情,偏偏寫了幾個(gè)類來(lái)實(shí)現(xiàn),那么這樣做是得不償失的)
工廠管理類? ：管理創(chuàng)建
父類： BaseCell
子類1：根據(jù)不同需求去實(shí)現(xiàn)邏輯代碼
子類2：
