函數(shù)式編程概念
一、編程方式
1.1 面向?qū)ο缶幊蘋OP冰更；
1.2?函數(shù)式編程Functional Programming：使用高階函數(shù)产徊，例如函數(shù)作為其他函數(shù)的參數(shù)；
1.3?響應式編程Reactive Programming：關注數(shù)據(jù)流和變化傳播蜀细；
1.4?函數(shù)響應式編程：Functional Reactive Programming舟铜，就是通常說的FRP。
二奠衔、函數(shù)式編程的特性
2.1?函數(shù)是“第一等公民”谆刨。
????函數(shù)與其他基礎數(shù)據(jù)類型一樣塘娶，處于平等地位∪玻可以賦值給其他變量刁岸，也可以作為參數(shù)，傳入另一個函數(shù)她我，或者作為別的函數(shù)的返回值虹曙。
2.2?閉包和高階函數(shù)。
? ? 閉包是起函數(shù)作用并且可以像對象一樣操作的對象番舆。與此類似酝碳，函數(shù)式編程語言也支持高階函數(shù)，高階函數(shù)可以用另一個函數(shù)作為其輸入?yún)?shù)恨狈，在大多數(shù)情況下疏哗，它甚至可以返回一個函數(shù)作為輸出參數(shù)。這兩種結(jié)構結(jié)合在一起禾怠，可以優(yōu)雅的進行模塊化編程返奉，這是使用函數(shù)式編程的最大好處。
2.3?不改變狀態(tài)（由此引申“引用透明”的概念）刃宵。
? ? 函數(shù)式編程只是返回新的值衡瓶，不修改系統(tǒng)狀態(tài)。在其他語言中牲证，變量往往用來保存“狀態(tài)”哮针，不修改變量，意味著狀態(tài)不能保存在變量中坦袍。函數(shù)式編程使用參數(shù)來保存狀態(tài)十厢，最好的例子就是遞歸。
? ? 引用透明捂齐。如果提供同樣的輸入蛮放，那么函數(shù)總是返回同樣的結(jié)果，就是說表達式的值奠宜，不依賴于可以改變值得全局狀態(tài)包颁。這就可以從形式上推斷程序行為，因此表達式的意義只取決于子表達式而不是計算順序或者其他表達式的副作用压真。
2.4?遞歸娩嚼。
? ? 函數(shù)式編程是用遞歸作為流程控制的機制。
2.5?“表達式”（expression）是一個單純的運算過程滴肿，總是有返回值岳悟；”語句”（statement）是執(zhí)行某種操作，沒有返回值。
? ? 函數(shù)式編程要求贵少，只使用表達式呵俏，不使用語句。也就是說滔灶，每一步都是單純的運算普碎，而且都有返回值。原因是函數(shù)式編程的開發(fā)動機宽气，一開始就是為了處理運算（computation）随常，不考慮系統(tǒng)的讀寫（I/O）潜沦√蜒模”語句”屬于讀寫操作，所以就被排斥在外唆鸡。函數(shù)式編程強調(diào)沒有”副作用”涝影，意味著函數(shù)要保持獨立，所有功能就是返回一個新的值争占，沒有其他行為燃逻，尤其是不得修改外部變量的值。
MVVM
一臂痕、MVC及問題
? ? ? ? MVC是Model —— View —— Controller伯襟，但是iOS開發(fā)者大多將其解釋成Massive —— View —— Controller（重量級視圖控制器），iOS開發(fā)中通常沒有指出網(wǎng)絡代碼握童、數(shù)據(jù)組織代碼所在的層級姆怪，導致Controller負責太多事情，導致代碼變得臃腫復雜澡绩。因此需要給視圖控制器（UIViewController）瘦身稽揭，對業(yè)務進一步分離。
傳統(tǒng)MVC模式工程解耦會出現(xiàn)以下問題：
（1）iOS開發(fā)過程中肥卡，狀態(tài)依賴（KVO）實現(xiàn)方式復雜溪掀，實用性小
（2）UIViewController比較復雜，代碼耦合性高
? ? ? ? 為了解決MVC工程解耦時遇到的問題步鉴，MVVM流程起來了揪胃。
二、MVVM的引入
? ? ? ? MVVM代表Model —— View —— ViewModel, 它主要解決Controller層復雜性高氛琢、耦合性高的問題喊递，幫助我們重新組織工程代碼。我將要在這里展示的 MVVM 的風格, 它跟 MVC 十分兼容艺沼，只要我們將 MVC中Controller層的代碼分開處理即可完成册舞。
（1）Model?在 MVVM 中沒有真正的變化。 取決于你的偏好, 你的 model 可能會或可能不會封裝一些額外的業(yè)務邏輯工作障般。我更傾向于把它當做一個容納表現(xiàn)數(shù)據(jù)-模型對象信息的結(jié)構體, 并在一個單獨的管理類中維護的創(chuàng)建/管理模型的統(tǒng)一邏輯调鲸。
（2）View包含實際 UI 本身(可以是 UIView 代碼, xib盛杰，storyboard), 可以包含視圖特定的邏輯, 或用戶操作的反饋。在 iOS 中這不僅需要 UIView 代碼和那些文件, 還包括部分UIViewController藐石。
（3）ViewModel這個術語本身比較疑惑, 因為它混搭了前面兩個我們已知的術語, 但卻是完全不同的東西即供。 它不是傳統(tǒng)模型層和視圖層的結(jié)合，它的職責之一就是作為一個中間層連接模型層(Model);它還承擔收集于微、解析和轉(zhuǎn)換數(shù)據(jù)的責任逗嫡。這將這留給了 view (controller) 一個更加清晰明確的任務:承載View層視圖，組織展示由 view-model 提供的數(shù)據(jù)株依。
對比兩種模式驱证，可以簡單的認為MVVM比MVC多了一個中間層View-Model?，可以理解為: 我們將Controller中的網(wǎng)絡請求代碼恋腕、數(shù)據(jù)管理代碼和部分業(yè)務代碼移動到了它擁有的View-Model?中抹锄。這樣UIViewController?就能夠?qū)Ｗ⒌呢撠烿iew的管理、界面流程跳轉(zhuǎn)荠藤。
盡管我們的代碼并有沒有減少伙单，代碼層次增加了，但是Controller由臃腫變得簡潔哈肖，由復雜變得清晰吻育。針對功能單一的層次代碼，我們易于理解淤井，也方便進行單元測試布疼。總的來說庄吼，MVVM模式更加適合iOS移動APP工程開發(fā)缎除。
