iOS中的設計模式有非常多，常用的就下面這四種
一.MVC設計模式（設計模式之王）
MVC根據角色劃分類，涉及到三個角色：
Model:模型保存應用程序的數據。
View：視圖是模型的可視化表示以及用戶交互的控件。
Controller:控制器是一個協調所有工作的中介者。它訪問模型中的數據並在視圖中展示它們，同時它們還監聽事件和操作數據。
一個MVC模式的好的實現也就意味着每一個對象都會被劃分到上面所說的組中。
我們可以很好的用下圖來描述通過控制器實現的視圖到模型的交互過程：
技術分享
模型會把任何數據的變更通知控制器，然後控制器更新視圖數據。視圖對象通知控制器用戶的操作，控制器要麼根據需要來更新模型，要麼檢索任何被請求的數據。
你可能在想爲什麼不能僅僅使用控制器，在一個類中實現視圖和模型，這樣貌似更加容易？
所有的這些都歸結於代碼關注點分離以及複用。在理想的狀態下，視圖應該和模型完全的分離。如果視圖不依賴某個實際的模型，那麼視圖就可以被複用來展示不同模型的數據。
舉個例子來說，如果將來你打算加入電影或者書籍到你的資料庫中，你仍然可以使用同樣的AlbumView去顯示電影和書籍數據。更進一步來說，如果你想創建一個新的與專輯有關聯的工程，你可以很簡單的複用Album類，因爲它不依賴任何視圖。這就是MVC的強大之處。
二.單例設計模式：
單例設計模式確保對於一個給定的類只有一個實例存在，這個實例有一個全局唯一的訪問點。它通常採用懶加載的方式在第一次用到實例的時候再去創建它。
注意：蘋果大量使用了此模式。例如：[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的這些方法都返回一個單例對象。
你很可能會想爲什麼這麼關心是否一個類有多個實例？畢竟代碼和內存都是廉價的，對嗎？
有一些情況下，只有一個實例顯得非常合理。舉例來說，你不需要有多個Logger的實例，除非你想去寫多個日誌文件。或者一個全局的配置處理類：實現線程安全的方式訪問共享實例是容易的，比如一個配置文件，有好多個類同時修改這個文件。
三、委託設計模式（Delegation）
這裏先了解下其他兩個設計模式，門面模式和裝飾器模式，而委託則是裝飾器模式中的經典實現；
門面模式：針對複雜的子系統提供了單一的接口，不需要暴漏一些列的類和API給用戶，你僅僅暴漏一個簡單統一的API。
裝飾器（Decorator）模式：裝飾器模式在不修改原來代碼的情況下動態的給對象增加新的行爲和職責，它通過一個對象包裝被裝飾對象的方法來修改類的行爲，這種方法可以做爲子類化的一種替代方法。
在Objective-C中，存在兩種非常常見的實現:Category(類別)和Delegation（委託）
Category(類別)：是一種不需要子類化就可以讓你能動態的給已經存在的類增加方法的強有力的機制。新增的方法是在編譯期增加的，這些方法執行的時候和被擴展的類的其它方法是一樣的。它可能與裝飾器設計模式的定義稍微有點不同，因爲Category(類別)不會保存被擴展類的引用。
Delegation(委託)：
委託作爲另外一個裝飾器模式，它是一種和其它對象交互的機制。舉例來說，當你使用UITableView的時候，你必須要實現tableView:numberOfRowsInSection:方法。
你不可能讓UITableView知道它需要在每個區域顯示多少行，因爲這些是應用特定的數據。因此計算每個區域需要顯示多少行的職責就給了UITableView的委託。這就讓UITableView類獨立於它要顯示的數據。
這裏通過一個圖來解釋當你創建UITableView的時候會發生什麼：
UITableView的職責就是顯示一個表格視圖。然而最終它需要一些它自身沒有的信息。那麼它就求助於它的委託，通過發送消息給委託來獲取信息。在Objective-C實現委託模式的時候，一個類可以通過協議（Protocol）來聲明可選以及必要的方法。
子類化一個對象，複寫需要的方法看起來好像更容易一點，但是考慮到你只能子類化一個類，如果你想一個對象作爲兩個或者更多對象的委託的話，使用子類化將不能實現。
注意:這個是一個重要的模式。蘋果在UIKit類中大量使用了它：UITableView, UITextView, UITextField, UIWebView, UIAlert, UIActionSheet, UICollectionView, UIPickerView,UIGestureRecognizer, UIScrollView等等等。
四、觀察者模式
在觀察者模式中，一個對象任何狀態的變更都會通知另外的對改變感興趣的對象。這些對象之間不需要知道彼此的存在，這其實是一種松耦合的設計。當某個屬性變化的時候，我們通常使用這個模式去通知其它對象。
此模式的通用實現中，觀察者註冊自己感興趣的其它對象的狀態變更事件。當狀態發生變化的時候，所有的觀察者都會得到通知。蘋果的推送通知（Push Notification）就是一個此模式的例子。
如果你要遵從MVC模式的概念，你需要讓模型對象和視圖對象在不相互直接引用的情況下通信。這正是觀察者模式的用武之地。
Cocoa通過通知（Notifications）和Key-Value Observing(KVO)來實現觀察者模式。
通知（Notifications）：
不要和遠程推送以及本地通知所混淆，通知是一種基於訂閱-發佈模式的模型，它讓發佈者可以給訂閱者發送消息，並且發佈者不需要對訂閱者有任何的瞭解。
通知在蘋果官方被大量的使用。舉例來說，當鍵盤彈出或者隱藏的時候，系統會獨立發送UIKeyboardWillShowNotification/UIKeyboardWillHideNotification通知。當你的應用進入後臺運行的時候，系統會發送一個UIApplicationDidEnterBackgroundNotification通知。
KVO Key-Value Observing：
它是一種機制，當指定的對象的屬性被修改後，KVO自動通知相應的觀察者。
使用KVO的步驟
第一步：註冊觀察者[message addObserver:self forKeyPath:kKVOPathKey options:NSKeyValueObservingOptionNew context:Nil];
第二步：更改主題對象屬性的值，即觸發發送更改的通知 _message.key = @"asdfasd";
第三步：在制定的回調函數中，處理收到的更改通知
第四步：註銷觀察者 [_message removeObserver:self forKeyPath:kKVOPathKey];
KVC
是指 NSKeyValueCoding，一個非正式的Protocol，提供一種機制來間接訪問對象的屬性。KVO 就是基於 KVC 實現的關鍵技術之一。
KVO
KVO的是KeyValue Observe的縮寫，是一個觀察者模式，觀察者在鍵值改變時會得到通知
1.註冊需要觀察的對象的屬性addObserver:forKeyPath:options:context:
2.實現observeValueForKeyPath:ofObject:change:context:方法，這個方法當觀察的屬性變化時會自動調用
3.取消註冊觀察removeObserver:forKeyPath:context: