在iOS開發中常用的設計模式有以下6種：

1.代理模式

2.觀察者模式

3.MVC模式

4.單例模式

5.策略模式

6.工廠模式

設計模式詳解：

在觀察者模式中，一個對象任何狀態的變更都會通知另外的對改變感興趣的對象。這些對象之間不需要知道彼此的存在，這其實是一種松耦合的設計。當某個屬性變化的時候，我們通常使用這個模式去通知其它對象。

此模式的通用實現中，觀察者注冊自己感興趣的其它對象的狀態變更事件。當狀態發生變化的時候，所有的觀察者都會得到通知。蘋果的推送通知（Push Notification）就是一個此模式的例子。

如果你要遵從MVC模式的概念，你需要讓模型對象和視圖對象在不相互直接引用的情況下通信。這正是觀察者模式的用武之地。

Cocoa通過通知（Notifications）和Key-Value Observing(KVO)來實現觀察者模式。

一）代理模式

在cocoa框架中的Delegate模式中，委托人往往是框架中的對象（視圖中的控件、表視圖神馬的），代理人往往是視圖控制器對象。

應用場景：當一個類的某些功能需要由別的類來實現，但是又不確定具體會是哪個類實現。

優勢：解耦合

敏捷原則：開放-封閉原則

實例：tableview的 數據源delegate，通過和protocol的配合，完成委托訴求。

列表row個數delegate

自定義的delegate

（二）觀察者模式

在軟件開發中，無論是那種高級語言中總會伴隨著一些最為常用的設計模式，即便就如iOS開發中與我們打交道最多的無非就是單例模式、觀察者模式和工廠模式了，當然了其他的設置模式也同樣存在在編程的很多地方。下面就就讓我們簡單的了解下觀察者模式吧!

觀察者模式本質上時一種發布-訂閱模型,用以消除具有不同行為的對象之間的耦合，通過這一模式，不同對象可以協同工作，同時它們也可以被復用于其他地方Observer從Subject訂閱通知，ConcreteObserver實現重現ObServer并將其重載其update方法。一旦SubJect的實例需要通知Observer任何新的變更，Subject會發送update消息來通知存儲在其內部類中所注冊的Observer、在ConcreteObserver的update方法的實際實現中，Subject的內部狀態可被取得并進行后續處理。其類圖如下:

由上面我們可以發現觀察者模式無非在是定義對象間的一種一對多的依賴關系，并且當一個對象的狀態發生改變的時候，所有依賴于它的對象都會得到通知且自動更新。即如果Subject允許其他觀察者(實現了觀察者接口的對象)對這個Subject的改變進行請閱，當Subject發送了變化，那么Subject會將這個變化發送給所有的觀察者，觀察者就能對Subject的變化做出更新。其時序圖如下：

通過上面的觀察我們可以發現如果用N個Observer來拓展Subject的行為，這些Observer具有處理存儲在Subject中的信息的特定實現，這樣也就實現了前面所說的消除不同對象間的耦合的功能了。

那么了解了這些我們可能就會更像了解下我們在什么時候才會去使用觀察者模式呢？

當需要將改變通知所有的對象時，而你又不知道這些對象的具體類型

改變發生在同一個對象中，并需要改變其他對象將相關的狀態進行更新且不知道有多少個對象。

應用場景：一般為model層對，controller和view進行的通知方式，不關心誰去接收，只負責發布信息。

優勢：解耦合

敏捷原則：接口隔離原則，開放-封閉原則

實例：Notification通知中心，注冊通知中心，任何位置可以發送消息，注冊觀察者的對象可以接收。

kvo，鍵值對改變通知的觀察者，平時基本沒用過。

而同樣的在我們日常的開發中在Cocoa Touch框架中的的兩種經常打交道的技術KVO與通知都實現了觀察者模式，所以下面我們討論的重點也就是基于這兩個方面的。

通知

在之前的博文中曾經簡單的提到過一些通知的基礎使用方法，所以一些基本的使用方法再次就不贅述。言歸正傳，在Cocoa Touch框架中NSNotificationCenter和NSNotification對象實現了一對多的模型。通過NSNotificationCenter可以讓對象之間進行通訊，即便這些對象之間并不認識。

KVO

是Cocoa提供的一種稱為鍵值觀察的機制，對象可以通過它得到其他對象特定屬性的變更通知。而這個機制是基于NSKeyValueObserving非正式些，Cocoa通過這個協議為所有遵循協議的對象提供了一種自動化的屬性監聽的功能。

雖然通知和KVO都可以對觀察者進行實現，但是他們之間還是略有不同的，由上面的例子我們可以看出通知是由一個中心對象為所有觀察者提供變更通知，主要是廣義上關注程序事件，而KVO則是被觀察的對象直接想觀察者發送通知，主要是綁定于特定對象屬性的值。

（三）MVC模式

MVC根據角色劃分類，涉及到三個角色：

Model:模型保存應用程序的數據。

View：視圖是模型的可視化表示以及用戶交互的控件。

Controller:控制器是一個協調所有工作的中介者。它訪問模型中的數據并在視圖中展示它們，同時它們還監聽事件和操作數據。

一個MVC模式的好的實現也就意味著每一個對象都會被劃分到上面所說的組中。

我們可以很好的用下圖來描述通過控制器實現的視圖到模型的交互過程：

模型會把任何數據的變更通知控制器，然后控制器更新視圖數據。視圖對象通知控制器用戶的操作，控制器要么根據需要來更新模型，要么檢索任何被請求的數據。

你可能在想為什么不能僅僅使用控制器，在一個類中實現視圖和模型，這樣貌似更加容易？

所有的這些都歸結于代碼關注點分離以及復用。在理想的狀態下，視圖應該和模型完全的分離。如果視圖不依賴某個實際的模型，那么視圖就可以被復用來展示不同模型的數據。

舉個例子來說，如果將來你打算加入電影或者書籍到你的資料庫中，你仍然可以使用同樣的AlbumView去顯示電影和書籍數據。更進一步來說，如果你想創建一個新的與專輯有關聯的工程，你可以很簡單的復用Album類，因為它不依賴任何視圖。這就是MVC的強大之處。

應用場景：是一中非常古老的設計模式，通過數據模型，控制器邏輯，視圖展示將應用程序進行邏輯劃分。

優勢：使系統，層次清晰，職責分明，易于維護

敏捷原則：對擴展開放-對修改封閉

實例：model-即數據模型，view-視圖展示，controller進行UI展現和數據交互的邏輯控制。

（四）單例模式

單例設計模式確保對于一個給定的類只有一個實例存在，這個實例有一個全局唯一的訪問點。它通常采用懶加載的方式在第一次用到實例的時候再去創建它。

注意：蘋果大量使用了此模式。例如：[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的這些方法都返回一個單例對象。

你很可能會想為什么這么關心是否一個類有多個實例？畢竟代碼和內存都是廉價的，對嗎？

有一些情況下，只有一個實例顯得非常合理。舉例來說，你不需要有多個Logger的實例，除非你想去寫多個日志文件。或者一個全局的配置處理類：實現線程安全的方式訪問共享實例是容易的，比如一個配置文件，有好多個類同時修改這個文件。

應用場景：確保程序運行期某個類，只有一份實例，用于進行資源共享控制。

優勢：使用簡單，延時求值，易于跨模塊

敏捷原則：單一職責原則

實例：[UIApplication sharedApplication]。

注意事項：確保使用者只能通過 getInstance方法才能獲得，單例類的唯一實例。

java，C++中使其沒有公有構造函數，私有化并覆蓋其構造函數。

object c中，重寫allocWithZone方法，保證即使用戶用 alloc方法直接創建單例類的實例，

返回的也只是此單例類的唯一靜態變量。

（五）策略模式

定 義一系列的算法,把每一個算法封裝起來, 并且使它們可相互替換。本模式使得算法可獨立于使用它的客戶而變化。 也稱為 政策模式 (Policy) 。

當存在以下情況時使用Strategy模式

1）? 許多相關的類僅僅是行為有異。 “策略”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統需要動態地在幾種算法中選擇一種。

2）? 需要使用一個算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的算法。當這些變體實現為一個算法的類層次時 ,可以使用策略模式。

3）? 算法使用客戶不應該知道的數據。可使用策略模式以避免暴露復雜的、與算法相關的數據結構。

4）? 一個類定義了多種行為 , 并且這些行為在這個類的操作中以多個條件語句的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。

Strategy模式有下面的一些優點：

1) 相關算法系列

Strategy類層次為Context定義了一系列的可供重用的算法或行為。 繼承有助于析取出這些算法中的公共功能。

2) 提供了可以替換繼承關系的辦法

： 繼承提供了另一種支持多種算法或行為的方法。你可以直接生成一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編制到 Context中，而將算法的實現與Context的實現混合起來,從而使Context難以理解、難以維護和難以擴展，而且還不能動態地改變算法。最后你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的算法或行為。 將算法封裝在獨立的Strategy類中使得你可以獨立于其Context改變它，使它易于切換、易于理解、易于擴展。

3) 消除了一些if else條件語句

：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件語句來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件語句。含有許多條件語句的代碼通常意味著需要使用Strategy模式。

4) 實現的選擇

Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取舍要求從不同策略中進行選擇。

Strategy模式缺點 :

1)客戶端必須知道所有的策略類，并自行決定使用哪一個策略類

:? 本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。

2 ) Strategy和Context之間的通信開銷

：無論各個ConcreteStrategy實現的算法是簡單還是復雜, 它們都共享Strategy定義的接口。因此很可能某些 ConcreteStrategy不會都用到所有通過這個接口傳遞給它們的信息；簡單的 ConcreteStrategy可能不使用其中的任何信息！這就意味著有時Context會創建和初始化一些永遠不會用到的參數。如果存在這樣問題 , 那么將需要在Strategy和Context之間更進行緊密的耦合。

3 )策略模式將造成產生很多策略類

：可以通過使用享元模式在一定程度上減少對象的數量。 增加了對象的數目 Strategy增加了一個應用中的對象的數目。有時你可以將 Strategy實現為可供各Context共享的無狀態的對象來減少這一開銷。任何其余的狀態都由 Context維護。Context在每一次對Strategy對象的請求中都將這個狀態傳遞過去。共享的 Strategy不應在各次調用之間維護狀態。

應用場景：定義算法族，封裝起來，使他們之間可以相互替換。

優勢：使算法的變化獨立于使用算法的用戶

敏捷原則：接口隔離原則；多用組合，少用繼承；針對接口編程，而非實現。

實例：排序算法，NSArray的sortedArrayUsingSelector；經典的鴨子會叫，會飛案例。

注意事項：1，剝離類中易于變化的行為，通過組合的方式嵌入抽象基類

2，變化的行為抽象基類為，所有可變變化的父類

3，用戶類的最終實例，通過注入行為實例的方式，設定易變行為

防止了繼承行為方式，導致無關行為污染子類。完成了策略封裝和可替換性。

（六）工廠模式

工廠模式我的理解是：他就是為了創建對象的。

創建對象的時候，我們一般是alloc一個對象，如果需要創建100個這樣的對象，如果是在一個for循環中還好說，直接一句alloc就行了，但是事實并不那么如意，我們可能會在不同的地方去創建這個對象，那么我們可能需要寫100句alloc 了，但是如果我們在創建對象的時候，需要在這些對象創建完之后，為它的一個屬性添加一個固定的值，比方說都是某某學校的學生，那么可能有需要多些100行重復的代碼了，那么，如果寫一個-(void)createObj方法，把創建對象和學校屬性寫在這個方法里邊，那么就是會省事很多，也就是說我們可以alloc 創建對象封裝到一個方法里邊，直接調用這個方法就可以了，這就是簡單工廠方法。

但是工廠方法也有它的限制：

1.要創建的類必須擁有同一個父類

2.要創建的類在100個不同的地方所調用的方法必須一樣。

應用場景：工廠方式創建類的實例，多與proxy模式配合，創建可替換代理類。

優勢：易于替換，面向抽象編程，application只與抽象工廠和易變類的共性抽象類發生調用關系。

敏捷原則：DIP依賴倒置原則

實例：項目部署環境中依賴多個不同類型的數據庫時，需要使用工廠配合proxy完成易用性替換

注意事項：項目初期，軟件結構和需求都沒有穩定下來時，不建議使用此模式，因為其劣勢也很明顯，

增 加了代碼的復雜度，增加了調用層次，增加了內存負擔。所以要注意防止模式的濫用。