【iOS】關於設計模式的小小總結

在軟件開發中，不管是什麼開發語言總會伴隨着一下常見的設計模式，如MVC模式、代理模式、單例模式等等。下面就對開發中經常使用的一下模式進行概括整理。

首先先說一下什麼是設計模式？

設計模式是一種編程經驗，就是用比較成熟的邏輯來處理某一類型的事情。有了它咱們就能夠比較清晰明瞭的來處理開發中遇到的問題。

在iOS中經常使用的設計模式有哪些？

在開發中經常使用的設計模式包含單例模式、觀察者模式、代理模式、工廠模式、策略模式、MVC模式以及MVC的變種MVVM模式。

以上就是經常使用的設計模式，固然還有一些不經常使用的模式，如中介者模式、組合模式等

 

下面我就一一解釋經常使用的設計模式

1、單例模式

單例模式能夠保證APP在程序運行中，一個類有且只有惟一一個實例（即不管請求建立多少次，始終返回同一個實例），而且在整個APP程序中，這一份資源是共享的。它一般採用懶加載的方式在第一次用到實例的時候再去建立。

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

敏捷原則：單一職責原則

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

我的理解：

不少狀況下咱們並不會關心一個類是否有多個實例，佔多少內存的問題。但是在一些狀況下，只有一個實例顯得很是合理。舉例來講，咱們有一個配置文件，可是有好多歌類同時修改這個文件，咱們建立一個單例就顯得很合理了。

2、觀察者模式

觀察者模式本質上是一種發佈-訂閱模型，泳衣消除具備不一樣行爲的對象之間的耦合。經過這一模式，不一樣對象之間能夠協同工做，同時他們也能夠被複用於其餘地方Observer從Subject訂閱通知，ConncrecteObserver實現重現Observer並將其重載其update方法。

一旦Subject的實例須要通知Observer任何新的變動，Subject就會發送update消息來通知存儲在其內部類中所註冊的Observer，在ConcreteObserver的update方法中，Subject的內部狀態可被獲取並進行後續處理。

優勢：解耦合

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

示例：Notification通知中心，註冊通知中心，任何位置均可以發送消息，註冊觀察者的對象均可以接收消息；KVO鍵值對改變通知的觀察者等

我的理解：

通常爲model層，對從controller和view進行的通知方式，不關心誰去接受，只負責發佈消息。

3、代理模式

代理模式是一種消息傳遞方式，一個完整的代理模式包括：委託對象，代理對象和協議。

協議「用來指定代理雙方能夠作什麼，必須作什麼。

委託對象：根據協議指定代理對象須要完成的事，即調用協議中的方法。

代理對象：根據協議實現委託方須要完成的事，即實現協議中的方法。 

代理模式完成委託方交給的任務，委託方有一些任務本身不想完成，可是還須要實現，擇將該任務存放在協議中，由代理完成。可是代理並不會主動的執行任務，須要委託方通知代理。

優勢：解耦合

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

示例：tableview的 數據源delegate；列表row個數delegate；自定義的delegate等

我的理解：

當一個類的某些功能須要由別的類來實現，可是又不肯定具體會是哪一個類實現。可使用代理。舉個例子，我在公司敲代碼，忽然想吃水果，這是我就拿起手機去每日生鮮訂一份水果，而後每日生鮮會下單給店鋪並讓店鋪給我送過來。這個過程當中，我是委託方，APP是個人代理，我買了一份水果並付給APP錢，這就是購買協議。我只須要從APP上都賣，其他操做都是APP去處理。我付的錢就是參數，送過來的水果就是處理結果。再買水果的同事我還能夠定外賣，這時須要用到餓了麼APP。餓了麼當個人代理。這就是多個代理對象。實現一對多。

4、工廠模式

專門定義一個類來負責建立其餘類的實例，被建立的實例痛楚具備共同的父類。簡單來講就是定義一個抽象類，抽象類中生命公共的特徵及屬性，抽象子類繼承抽象類，趨勢線具體的操做。工廠類根據外界需求，在工廠類中建立對應的抽象子類實例並傳給外界，而對象的建立室友外界決定的，外界只須要知道抽象子類對應參數便可，並不須要抽象子類的建立過程，在外界使用甚至不用引入抽象子類。

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

經過簡單工廠模式的重構，咱們就實現了低耦合度的代碼結構，作到了對外擴展開放，對修改關閉。若是再增長任何的操做方法，只須要繼承操做方法父類，新建一個操做子類，而且在簡單工廠類裏面多添加一個else if的判斷便可。

缺點：工廠類集中了全部產品的建立邏輯，一旦不能正常工做，整個系統都會受到影響，並且當產品類多、結構複雜時，把全部的建立工做放在一個工廠中，後期擴展維護比較困難。

敏捷原則：DIP一來倒置原則

示例：工廠方式建立類的實例，多與proxy模式配合，建立可替換代理類。如項目部署環境中依賴多個不一樣類型的數據庫時，須要使用工廠配合proxy完成易用性替換 

我的理解：

我認爲工廠模式就是爲了建立對象的。通常來講咱們建立對象都是alloc一個，若是須要建立100個，在for循環中還好。但是實際中每每不是如此。咱們可能會在不一樣的地方去建立，難道咱們要寫100次？而且若是咱們在建立時給屬性添加值，那就更復雜了。那麼咱們若是寫一個父類並在裏面寫一個createObj的方法，把建立和賦值寫在方法裏，而後都繼承這個父類這不就簡單不少了。這就是簡單工程方法。這也說明了工廠類的限制，就是建立的類必須有同一個父類，並且建立的類在不一樣地方調用的方法一致。

在項目初期，軟件結構和需求都沒有穩定下來時，不建議使用此模式。

5、策略模式

策略模式定義了一系列的算法，並將每個算法封裝起來，並且使他們還能夠互相替換。使算法自己和使用算法的用戶分割開來，互相獨立

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

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

我的理解：

舉一個簡單的例子，就像地圖APP中，肯定起始點和目的地後咱們能夠選擇不一樣的出行方式（步行、公交、私家車等）。 

6、MVC模式

MVC模式是一種古老的軟件設計典範。經過數據模型，控制器邏輯，視圖展現將應用程序進行邏輯劃分。將控制器邏輯彙集在一個部件中，在改進頁面和交互是不須要從新編寫業務邏輯。

MVC涉及的三個角色：

Model：模型對象用來封裝應用程序的數據，並定義操做和處理該數據的邏輯和運算。

View：試圖對象是用戶在應用程序中能夠看到的對象。它知道如何將本身展現繪製出來，並對用戶的操做作出反應。

Controller：控制器是一個協調全部工做的中介者。它訪問模型中的數據並在視圖中展現它們，同時它們還監聽事件和操做數據。經過它，視圖能夠了解模型的更改，反之亦然。控制器對象還能夠爲應用程序執行設置和協調人物，並管理其餘對象的生命週期。

優勢：是系統層次清晰，職責分明，易於維護。

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

我的理解：

一個MVC模式的好的實現也就意味着每個對象都會被劃分到上面的三種角色中。能夠用下圖來協助理解。

模型會把數據的變動通知控制器，而後控制器更新視圖數據。

試圖對象通知控制器用戶的操做，控制器要麼根據需求來更新模型，要麼檢索任何被請求的數據。

 7、MVVM模式

在iOS應用日益增加的重量級控制器的情形下，典型的MVC模式中，許多邏輯被安放在ViewController中。他們中的一些確實屬於viewController，但更多的是所謂的表示邏輯。爲了避免讓控制器日益增大，便於管理便出現了MVVM。

MVVM是MVC的加強版，並將表示邏輯從Controller中移出放在一個新的對象裏面，即ViewModel。在iOS中使用MVVM的動機就是爲了減小ViewController的複雜性並使得表示邏輯更易於測試。

ViewModel：位於ViewController和Model之間，是二者的溝通橋樑，是一些邏輯的處理。

 

這就是我對於常見設計模式的一些整理概括，才疏學淺，若有問題，敬請指教。