一? iOS中都有什么設計模式？
iOS中分別有以下設計模式：
1.代理模式 ? ?2.觀察者模式 ??3.MVC模式 ?4.單例模式 ??5.策略模式 ? ?6.工廠模式
二 ?各個設計模式的作用？
（一）代理模式
在cocoa框架中的Delegate模式中，委托人往往是框架中的對象（視圖中的控件、表視圖神馬的），代理人往往是視圖控制器對象。
在我們這個例子中UITableView是委托人，代理人首先得滿足一個條件：申明它擁有代理資格（我給它簡化了一個標識公式為：對象.delegate = 對象）
當這個委托人需要辦事時，此人不用自己去做，代理人自己就站出來幫忙辦了。這就是ios中的Delegate模式。
當一個類的某些功能需要被別人來實現(xiàn)，但是既不明確是些什么功能，又不明確誰來實現(xiàn)這些功能的時候，委托模式就可以派上用場。
例如你可以再寫個C類，實現(xiàn)-(void)transparendValue:(NSString*)fromValue {NSLog(@"%@ ,我是C",value); }也是完全可以的。換誰來，只要它實現(xiàn)了這個方法，我就可以委托它來做這個事。
說到底一切都是為了使類之間的耦合性更松散。好的代碼應該對擴展開放，對修改關閉。
（一）.觀察者模式
在觀察者模式中，一個對象任何狀態(tài)的變更都會通知另外的對改變感興趣的對象。這些對象之間不需要知道彼此的存在，這其實是一種松耦合的設計。當某個屬性變化的時候，我們通常使用這個模式去通知其它對象。
觀察者模式本質上時一種發(fā)布-訂閱模型,用以消除具有不同行為的對象之間的耦合，通過這一模式，不同對象可以協(xié)同工作。
那么了解了這些我們可能就會更像了解下我們在什么時候才會去使用觀察者模式呢？
當需要將改變通知所有的對象時，而你又不知道這些對象的具體類型
改變發(fā)生在同一個對象中，并需要改變其他對象將相關的狀態(tài)進行更新且不知道有多少個對象。
此模式的通用實現(xiàn)中，觀察者注冊自己感興趣的其它對象的狀態(tài)變更事件。當狀態(tài)發(fā)生變化的時候，所有的觀察者都會得到通知。蘋果的推送通知（Push Notification）就是一個此模式的例子。
Cocoa通過通知（Notifications）和Key-Value Observing(KVO)來實現(xiàn)觀察者模式。
最后記得銷毀，尤其是KVO,還有一點需要說的是使用KVO時一定要實現(xiàn)方法：
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context；
不然會崩。
（三）MVC模式
MVC根據(jù)角色劃分類，涉及到三個角色：
Model:模型保存應用程序的數(shù)據(jù)。
Controller:控制器是一個協(xié)調所有工作的中介者。它訪問模型中的數(shù)據(jù)并在視圖中展示它們，同時它們還監(jiān)聽事件和操作數(shù)據(jù)。
一個MVC模式的好的實現(xiàn)也就意味著每一個對象都會被劃分到上面所說的組中。
我們可以很好的用下圖來描述通過控制器實現(xiàn)的視圖到模型的交互過程：
模型會把任何數(shù)據(jù)的變更通知控制器，然后控制器更新視圖數(shù)據(jù)。視圖對象通知控制器用戶的操作，控制器要么根據(jù)需要來更新模型，要么檢索任何被請求的數(shù)據(jù)。
所有的這些都歸結于代碼關注點分離以及復用。在理想的狀態(tài)下，視圖應該和模型完全的分離。如果視圖不依賴某個實際的模型，那么視圖就可以被復用來展示不同模型的數(shù)據(jù)。
（四）單例模式
單例設計模式確保對于一個給定的類只有一個實例存在，這個實例有一個全局唯一的訪問點。它通常采用懶加載的方式在第一次用到實例的時候再去創(chuàng)建它。
注意：蘋果大量使用了此模式。例如：[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的這些方法都返回一個單例對象。
有一些情況下，只有一個實例顯得非常合理。舉例來說，你不需要有多個Logger的實例，除非你想去寫多個日志文件。或者一個全局的配置處理類：實現(xiàn)線程安全的方式訪問共享實例是容易的，比如一個配置文件，有好多個類同時修改這個文件。
（五）策略模式
當一個問題有多種實現(xiàn)方式，可是需要在不同的情況下用不同的實現(xiàn)方式來解決時，我們可能首先想到if ...else..的模式，可是這樣一來我們就把情況定死了，也稱為硬編碼。當產品需求發(fā)生改變的時候且不在我們所定義的情況之內，那此時就需要來改變我們原先寫好的代碼。
那此時我們就需要在寫代碼之前考慮：讓算法和對象分開來，使得算法可以獨立于使用它的客戶而變化。
策略模式： 定義一系列的算法,把每一個算法封裝起來, 并且使它們可相互替換。本模式使得算法可獨立于使用它的客戶而變化。也稱為 政策模式 (Policy)。（ Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it.? ）
策略模式把對象本身和運算規(guī)則區(qū)分開來，其?功能非常強大，因為這個設計模式本身的核心思想就是面向對象編程的多形性的思想。
當存在以下情況時使用Strategy模式
1）? 許多相關的類僅僅是行為有異。 “策略”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統(tǒng)需要動態(tài)地在幾種算法中選擇一種。
2）? 需要使用一個算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的算法。當這些變體實現(xiàn)為一個算法的類層次時 ,可以使用策略模式。
3）? 算法使用客戶不應該知道的數(shù)據(jù)?？墒褂貌呗阅Ｊ揭员苊獗┞稄碗s的、與算法相關的數(shù)據(jù)結構。
4）? 一個類定義了多種行為 , 并且這些行為在這個類的操作中以多個條件語句的形式出現(xiàn)。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。
Strategy模式有下面的一些優(yōu)點：
1) 相關算法系列
Strategy類層次為Context定義了一系列的可供重用的算法或行為。?繼承有助于析取出這些算法中的公共功能。
2) 提供了可以替換繼承關系的辦法
： 繼承提供了另一種支持多種算法或行為的方法。你可以直接生成一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編制到 Context中，而將算法的實現(xiàn)與Context的實現(xiàn)混合起來,從而使Context難以理解、難以維護和難以擴展，而且還不能動態(tài)地改變算法。最后你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的算法或行為。?將算法封裝在獨立的Strategy類中使得你可以獨立于其Context改變它，使它易于切換、易于理解、易于擴展。
3) 消除了一些if else條件語句
：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件語句來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件語句。含有許多條件語句的代碼通常意味著需要使用Strategy模式。
4) 實現(xiàn)的選擇
Strategy模式可以提供相同行為的不同實現(xiàn)?？蛻艨梢愿鶕?jù)不同時間 /空間權衡取舍要求從不同策略中進行選擇。
Strategy模式缺點:
1)客戶端必須知道所有的策略類，并自行決定使用哪一個策略類
: ?本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現(xiàn)問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通信開銷
：無論各個ConcreteStrategy實現(xiàn)的算法是簡單還是復雜, 它們都共享Strategy定義的接口。因此很可能某些 ConcreteStrategy不會都用到所有通過這個接口傳遞給它們的信息；簡單的 ConcreteStrategy可能不使用其中的任何信息！這就意味著有時Context會創(chuàng)建和初始化一些永遠不會用到的參數(shù)。如果存在這樣問題 , 那么將需要在Strategy和Context之間更進行緊密的耦合。
3 )策略模式將造成產生很多策略類
：可以通過使用享元模式在一定程度上減少對象的數(shù)量。 增加了對象的數(shù)目 Strategy增加了一個應用中的對象的數(shù)目。有時你可以將 Strategy實現(xiàn)為可供各Context共享的無狀態(tài)的對象來減少這一開銷。任何其余的狀態(tài)都由 Context維護。Context在每一次對Strategy對象的請求中都將這個狀態(tài)傳遞過去。共享的 Strategy不應在各次調用之間維護狀態(tài)。
iOS應用分析
例如，我們在驗證用戶輸入的表單的時候，加入包括電話輸入框的驗證和郵件輸入框的驗證，這兩部分的驗證算法是不同的，如果把這個算法看成一個函數(shù)，他幾乎有相同的輸入?yún)?shù)和返回參數(shù)。我們可以把這個相同的函數(shù)可以抽象為基類(InputValidator)的一個方法(bool validateInput(input,error))，然后抽象出兩個具體的策略類：電話驗證類(PhoneValidator)和郵件驗證類(EmailValidator)，他們需要在各自的實現(xiàn)里面去復寫父類的驗證方法。為了能夠正常的調用到驗證類的驗證方法，我們需要自定義一個UITextField的子類CustomTextField，其中有一個InputValidator類型的引用和一個validate方法，該方法里面調用InputValidator的驗證方法，然后在textFieldDidEndEditing代理方法里面調用CustomTextField的validate方法，這樣就不用我們在判斷輸入是否合法的時候通過if else去處理每種邏輯，而且這樣做方便擴展，提高可復用性。
實例：排序算法，NSArray的sortedArrayUsingSelector；經典的鴨子會叫，會飛案例。
（六）工廠模式
工廠模式我的理解是：他就是為了創(chuàng)建對象的
創(chuàng)建對象的時候，我們一般是alloc一個對象，如果需要創(chuàng)建100個這樣的對象，如果是在一個for循環(huán)中還好說，直接一句alloc就行了，但是事實并不那么如意，我們可能會在不同的地方去創(chuàng)建這個對象，那么我們可能需要寫100句alloc 了，但是如果我們在創(chuàng)建對象的時候，需要在這些對象創(chuàng)建完之后，為它的一個屬性添加一個固定的值，比方說都是某某學校的學生，那么可能有需要多些100行重復的代碼了，那么，如果寫一個-(void)createObj方法，把創(chuàng)建對象和學校屬性寫在這個方法里邊，那么就是會省事很多，也就是說我們可以alloc 創(chuàng)建對象封裝到一個方法里邊，直接調用這個方法就可以了，這就是簡單工廠方法
工廠方法模式是為每一個要創(chuàng)建的對象所在的類都相應地創(chuàng)建一個工廠
但是工廠方法也有它的限制：
1.要創(chuàng)建的類必須擁有同一個父類
2.要創(chuàng)建的類在100個不同的地方所調用的方法必須一樣
以上是我對ios常用到的設計模式的一些總結，也歡迎大家指正、討論。
參考：http://www.cnblogs.com/dxb123456/p/5479198.html
