分類
創(chuàng)建型 (Creational)：
單例模式 (Singleton)
結(jié)構(gòu)型 (Structural)：
MVC沟堡、裝飾者模式 (Decorator)毫炉、適配器模式 (Adapter)疑枯、外觀模式 (Facade)
行為型 (Behavioral)：
觀察者模式 (Observer)、備忘錄模式 (Memento)
單例模式 - Singleton
在 iOS 中單例模式很常見(jiàn)靴寂，UserDefaults.standard、 UIApplication.shared 召耘、 UIScreen.main 百炬、 FileManager.default 這些都是單例模式。
設(shè)計(jì)模式之王- MVC
模型層 (Model) ：
存儲(chǔ)數(shù)據(jù)并且定義如何操作這些數(shù)據(jù)污它。
視圖層 (View) ：
負(fù)責(zé)模型層的可視化展示剖踊，并且負(fù)責(zé)用戶的交互，一般來(lái)說(shuō)都是繼承自 UIView 這個(gè)基類衫贬。
控制器 (Controller) ：
控制器是整個(gè)系統(tǒng)的掌控者德澈，它連接了模型層和數(shù)據(jù)層，并且把數(shù)據(jù)在視圖層展示出來(lái)祥山，監(jiān)聽(tīng)各種事件圃验，負(fù)責(zé)數(shù)據(jù)的各種操作。
另外：Model-View-ViewModel(MVVM)
裝飾者模式 - Decorator
裝飾者模式可以動(dòng)態(tài)的給指定的類添加一些行為和職責(zé)缝呕，而不用對(duì)原代碼進(jìn)行任何修改澳窑。當(dāng)你需要使用子類的時(shí)候斧散，不妨考慮一下裝飾者模式，可以在原始類上面封裝一層摊聋。
在 Swift 里鸡捐，有兩種方式實(shí)現(xiàn)裝飾者模式：擴(kuò)展 (Extension) 和委托 (Delegation)。
擴(kuò)展
擴(kuò)展是一種十分強(qiáng)大的機(jī)制麻裁，可以讓你在不用繼承的情況下箍镜，給已存在的類、結(jié)構(gòu)體或者枚舉類添加一些新的功能煎源。最重要的一點(diǎn)是色迂，你可以在你沒(méi)有訪問(wèn)權(quán)限的情況下擴(kuò)展已有類。這意味著你甚至可以擴(kuò)展 Cocoa 的類手销，比如 UIView 或者 UIImage 歇僧。
舉個(gè)例子，在編譯時(shí)新加的方法可以像擴(kuò)展類的正常方法一樣執(zhí)行锋拖。這和裝飾器模式有點(diǎn)不同诈悍，因?yàn)閿U(kuò)展不會(huì)持有擴(kuò)展類的對(duì)象。
委托
裝飾者模式的另一種實(shí)現(xiàn)方案是委托兽埃。在這種機(jī)制下侥钳，一個(gè)對(duì)象可以和另一個(gè)對(duì)象相關(guān)聯(lián)。比如你在用 UITableView 柄错，你必須實(shí)現(xiàn) tableView(_:numberOfRowsInSection:) 這個(gè)委托方法舷夺。
你不應(yīng)該指望 UITableView 知道你有多少數(shù)據(jù)，這是個(gè)應(yīng)用層該解決的問(wèn)題鄙陡。所以冕房，數(shù)據(jù)相關(guān)的計(jì)算應(yīng)該通過(guò) UITableView 的委托來(lái)解決。這樣可以讓 UITableView 和數(shù)據(jù)層分別獨(dú)立趁矾。視圖層就負(fù)責(zé)顯示數(shù)據(jù)耙册，你遞過(guò)來(lái)什么我就顯示什么。
適配器模式 - Adapter
適配器把自己封裝起來(lái)然后暴露統(tǒng)一的接口給其他類毫捣，這樣即使其他類的接口各不相同详拙，也能相安無(wú)事，一起工作蔓同。
如果你熟悉適配器模式饶辙，那么你會(huì)發(fā)現(xiàn)蘋(píng)果在實(shí)現(xiàn)適配器模式的方式稍有不同：蘋(píng)果通過(guò)委托實(shí)現(xiàn)了適配器模式。委托相信大家都不陌生斑粱。舉個(gè)例子弃揽，如果一個(gè)類遵循了 NSCoying 的協(xié)議，那么它一定要實(shí)現(xiàn) copy 方法。
外觀模式 - Facade
外觀模式在復(fù)雜的業(yè)務(wù)系統(tǒng)上提供了簡(jiǎn)單的接口矿微。如果直接把業(yè)務(wù)的所有接口直接暴露給使用者痕慢，使用者需要單獨(dú)面對(duì)這一大堆復(fù)雜的接口，學(xué)習(xí)成本很高涌矢，而且存在誤用的隱患掖举。如果使用外觀模式，我們只要暴露必要的 API 就可以了娜庇。
API 的使用者完全不知道這內(nèi)部的業(yè)務(wù)邏輯有多么復(fù)雜塔次。當(dāng)我們有大量的類并且它們使用起來(lái)很復(fù)雜而且也很難理解的時(shí)候，外觀模式是一個(gè)十分理想的選擇名秀。
外觀模式把使用和背后的實(shí)現(xiàn)邏輯成功解耦励负，同時(shí)也降低了外部代碼對(duì)內(nèi)部工作的依賴程度。如果底層的類發(fā)生了改變泰偿，外觀的接口并不需要做修改熄守。
舉個(gè)例子蜈垮，如果有一天你想換掉所有的后臺(tái)服務(wù)耗跛，你只需要修改 API 內(nèi)部的代碼，外部調(diào)用 API 的代碼并不會(huì)有改動(dòng)攒发。
觀察者模式 - Observer
在觀察者模式里调塌，一個(gè)對(duì)象在狀態(tài)變化的時(shí)候會(huì)通知另一個(gè)對(duì)象。參與者并不需要知道其他對(duì)象的具體是干什么的 - 這是一種降低耦合度的設(shè)計(jì)惠猿。這個(gè)設(shè)計(jì)模式常用于在某個(gè)屬性改變的時(shí)候通知關(guān)注該屬性的對(duì)象羔砾。
常見(jiàn)的使用方法是觀察者注冊(cè)監(jiān)聽(tīng)，然后再狀態(tài)改變的時(shí)候偶妖，所有觀察者們都會(huì)收到通知姜凄。
在 MVC 里，觀察者模式意味著需要允許 Model 對(duì)象和 View 對(duì)象進(jìn)行交流趾访，而不能有直接的關(guān)聯(lián)态秧。
Cocoa 使用兩種方式實(shí)現(xiàn)了觀察者模式： Notification 和 Key-Value Observing (KVO)。
備忘錄模式 - Memento
備忘錄模式捕捉并且具象化一個(gè)對(duì)象的內(nèi)在狀態(tài)扼鞋。換句話說(shuō)申鱼，它把你的對(duì)象存在了某個(gè)地方，然后在以后的某個(gè)時(shí)間再把它恢復(fù)出來(lái)云头，而不會(huì)打破它本身的封裝性捐友，私有數(shù)據(jù)依舊是私有數(shù)據(jù)。
歸檔 - Archiving
蘋(píng)果通過(guò)歸檔的方法來(lái)實(shí)現(xiàn)備忘錄模式溃槐。它把對(duì)象轉(zhuǎn)化成了流然后在不暴露內(nèi)部屬性的情況下存儲(chǔ)數(shù)據(jù)匣砖。
