分類(lèi)

創(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é)用戶(hù)的交互，一般來(lái)說(shuō)都是繼承自 UIView 這個(gè)基類(lèi)。

控制器 (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)的給指定的類(lèi)添加一些行為和職責(zé)，而不用對(duì)原代碼進(jìn)行任何修改。當(dāng)你需要使用子類(lèi)的時(shí)候，不妨考慮一下裝飾者模式，可以在原始類(lèi)上面封裝一層。

在 Swift 里，有兩種方式實(shí)現(xiàn)裝飾者模式：擴(kuò)展 (Extension) 和委托 (Delegation)。

擴(kuò)展

擴(kuò)展是一種十分強(qiáng)大的機(jī)制，可以讓你在不用繼承的情況下，給已存在的類(lèi)、結(jié)構(gòu)體或者枚舉類(lèi)添加一些新的功能。最重要的一點(diǎn)是，你可以在你沒(méi)有訪(fǎng)問(wèn)權(quán)限的情況下擴(kuò)展已有類(lèi)。這意味著你甚至可以擴(kuò)展 Cocoa 的類(lèi)，比如 UIView 或者 UIImage 。

舉個(gè)例子，在編譯時(shí)新加的方法可以像擴(kuò)展類(lèi)的正常方法一樣執(zhí)行。這和裝飾器模式有點(diǎn)不同，因?yàn)閿U(kuò)展不會(huì)持有擴(kuò)展類(lèi)的對(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)一的接口給其他類(lèi)，這樣即使其他類(lèi)的接口各不相同，也能相安無(wú)事，一起工作。

如果你熟悉適配器模式，那么你會(huì)發(fā)現(xiàn)蘋(píng)果在實(shí)現(xiàn)適配器模式的方式稍有不同：蘋(píng)果通過(guò)委托實(shí)現(xiàn)了適配器模式。委托相信大家都不陌生。舉個(gè)例子，如果一個(gè)類(lèi)遵循了 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)并且它們使用起來(lái)很復(fù)雜而且也很難理解的時(shí)候，外觀模式是一個(gè)十分理想的選擇。

外觀模式把使用和背后的實(shí)現(xiàn)邏輯成功解耦，同時(shí)也降低了外部代碼對(duì)內(nèi)部工作的依賴(lài)程度。如果底層的類(lè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)。換句話(huà)說(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ù)。