在iOS開發中經常用到的設計模式主要有以下幾種：
1.MVC模式
2.單例模式
3.代理模式
4.觀察者模式（一般分為：通知和KVO）
5.策略模式
6.工廠模式
一、MVC模式：
應用場景：是一種非常古老的框架級的設計模式，通過數據模型，控制器邏輯，視圖展示將應用程序進行邏輯劃分。（另外還有很多人用的是MVVM，有興趣的同學可以自行了解。）
優勢：使系統，層次清晰，職責分明，易于維護
原則：對擴展開放-對修改封閉
實例：model-即數據模型，view-視圖展示，controller進行UI展現和數據交互的邏輯控制。
Model:
模型保存應用程序的數據，定義了怎么去操作它。在開發過程中，從服務器請求到的數據必須要經過處理才能進行使用的，而處理過程，我們就可以寫在model中，這樣我們controller中的代碼就會變得更加簡潔、清晰、有條理。
View:
視圖是模型數據的可視化表示以及用戶交互的控件；基本上來說，所有的UIView對象以及它的子類都屬于視圖。在開發過程中，各個控件的創建，布局都可以寫在一個封裝好的view中，同樣可以使controller中的代碼變得簡潔。
Controller:
控制器是一個協調所有工作的中介者（Mediator，所以MVC模式有時也會稱為中介者模式）。它將model和view連接起來，將模型model中的數據在視圖中展示出來，同時它們還監聽事件和根據需要操作數據。主要負責同用戶間的交互。
在理想的狀態下，視圖應該和模型完全的分離（但是不容易做到）。如果視圖不依賴某個實際的模型，那么視圖就可以被復用來展示不同模型的數據。（比如一個APP的多個界面，上半部分是不同的界面布局，但是下半部分的視圖都是一個tableView且cell布局相同，只有內容不同，這個時候我們就可以復用這個tableView，只是給他傳遞不同的數據就可以了。）
二、單例模式：
應用場景：在程序運行期間，確保對于一個給定的類只有一個實例存在，這個實例有一個全局唯一的訪問點，用于進行資源共享控制。
優勢：使用簡單，延時求值，易于跨模塊。最主要的是因為只是創建一次，所以可以節省內存。
原則：單一職責原則
實例：
[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的這些方法都返回一個單例對象。下面是一個使用了單例模式新建和獲取實例的類模版，代碼如下：
.h文件
@interface Singleton : NSObject
+ (Singleton *)sharedSingleton; <1>
@end
.m文件
#import "Singleton.h"
@implementation Singleton
static Singleton *sharedSingleton = nil;<2>
+ (Singleton *)sharedSingleton{
static dispatch_once_t once;<3>
dispatch_once(&once,^{
sharedSingleton = [[self alloc] init];<4>
//只需要運行一次就可以滿足需求的代碼都可以寫在這里。
});
return sharedSingleton;<5>
}
上述代碼中有5小步，解釋如下：
- 聲明一個可以新建和獲取單個實例對象的方法
- 聲明一個static類型的類變量
- 聲明一個只執行一次的任務
- 調用dispatch_once執行該任務指定的代碼塊，在該代碼塊中實例化上文聲明的類變量
- 返回在整個應用的生命周期中只會被實例化一次的變量
以上就是iOS開發中單例模式的機制，
三、代理模式
應用場景：當一個類的某些功能需要由別的類來實現，但是又不確定具體會是哪個類實現。
優勢：解耦合
敏捷原則：開放-封閉原則
實例：tableview的 數據源delegate，通過和protocol的配合，完成委托訴求。
自定義的delegate
四、觀察者模式（一般分為：通知和KVO）
1、通知(notification)機制：Notification通知中心，注冊通知中心，任何位置可以發送消息，注冊觀察者的對象可以接收。（比如：一個愛唱歌的人，喜歡跟著音樂播放器里的歌聲來跟著哼哼，當播放器里進行切歌的時候，那么這個哼哼的曲調當然也就會跟著變化）。
第一步：注冊通知，即告訴通知中心，我對啥通知感興趣
[[NSNotificationCenter defaultCenter] addObserver: self selector: @selector(hengheng) name: @"切歌了" object: nil];
第二步：實現回調，如果有通知了，我需要干什么
- (void)callBack{
NSLog(@"唱得不好聽");
}
第三步：在程序任何一個地方都可以發送通知
//發出通知
[[NSNotificationCenter defaultCenter] postNotificationName:@"切歌了" object:self];
第四步（可選）：可以在需要的時候取消注冊通知。
[[NSNotificationCenter defaultCenter] removeObserver:self name:@"切歌了" object:nil];
2、KVO：，鍵值對改變通知的觀察者，平時基本沒用過。
KVO是觀察者設計模式中的一種實現方法。
五、策略模式（平時基本沒用過。）
應用場景：定義算法族，封裝起來，使他們之間可以相互替換。（在軟件開發中也常常遇到類似的情況，實現某一個功能有多種算法或者 策略，我們可以根據環境或者條件的不同選擇不同的算法或者策略來完成該功能 。如查找、排序等，一種常用的方法是硬編碼(Hard Coding)在一個類中，如需要提供多種查找算法，可以將這些算法寫到一個類中，在該類中提供多個方法，每一個方法對應一個具體的查找算法；當然也可以將這些查找算法封裝在一個統一的方法中，通過if…else…或者 case 等條件判斷語句來進行選擇。這兩種實現方法我們都可以稱之為硬編碼，如果需要增加一種新的查找算法，需要修改封裝算法類的源代碼；更換查找算法，也需要修改客戶端調用代碼。在這個算法類中封裝了大量查找算法， 該類代碼將較復雜，維護較為困難。如果我們將這些策略包含在客戶端 ，這種做法更不可取，將導致客戶端程序龐大而且難以維護，如果存在大量可供選擇的算法時問題將變得更加嚴重。）
優勢：使算法的變化獨立于使用算法的用戶
敏捷原則：接口隔離原則；多用組合，少用繼承；針對接口編程，而非實現。
實例：排序算法，NSArray的sortedArrayUsingSelector。
注意事項：1，剝離類中易于變化的行為，通過組合的方式嵌入抽象基類
2，變化的行為抽象基類為，所有可變變化的父類
3，用戶類的最終實例，通過注入行為實例的方式，設定易變行為
防止了繼承行為方式，導致無關行為污染子類。完成了策略封裝和可替換性。
六、工廠模式（平時基本沒用過。）
應用場景：工廠方式創建類的實例，多與proxy模式配合，創建可替換代理類。
優勢：易于替換，面向抽象編程，application只與抽象工廠和易變類的共性抽象類發生調用關系。
敏捷原則：DIP依賴倒置原則
實例：項目部署環境中依賴多個不同類型的數據庫時，需要使用工廠配合proxy完成易用性替換
注意事項：項目初期，軟件結構和需求都沒有穩定下來時，不建議使用此模式，因為其劣勢也很明顯，
增 加了代碼的復雜度，增加了調用層次，增加了內存負擔。所以要注意防止模式的濫用。
