iOS開發中的幾種設計模式

目前經常使用的幾種設計模式：代理模式、觀察者模式、MVC模式、單例模式、策略模式、工廠模式、MVVM

---

（一）代理 

場景：當一個類的某些功能須要由別的類來實現，可是又不肯定具體會是哪一個類實現。

優點：解耦合

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

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

列表row個數delegate

自定義的delegate

 

一句話總結：傳入對象實現對象的功能

---

（二）觀察者

場景：通常爲model層對，controller和view進行的通知方式，不關心誰去接收，只負責發佈信息。

優點：解耦合

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

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

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

---

（三）MVC

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

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

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

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

---

（四）單例

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

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

敏捷原則：單一職責原則

實例：[UIApplication sharedApplication]。

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

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

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

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

---

（五）策略

場景：定義算法族，封裝起來，使他們之間能夠相互替換。

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

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

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

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

2，變化的行爲抽象基類爲，全部可變變化的父類

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

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

---

（六）工廠

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

「專門定義一個類來負責建立其餘類的實例，被建立的實例一般具備共同的父類。」

世界上就是由一個工廠類，根據傳入的參數，動態地決定建立出哪個產品類的實例。

 

 

簡要分析結構圖：

ConcreteProduct1和ConcreteProduct2兩個產品具備一個共同的父類IProject，簡單工廠類爲SimpleFactory，負責根據傳入的不一樣參數來決定生產ConcreteProduct1仍是ConcreteProduct2產品。

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

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

         優勢：簡單工廠模式的優勢是客戶端能夠直接消費產品，而沒必要關心具體產品的實現，消除了客戶端直接建立產品對象的責任，實現了對責任的分割。

         缺點：是工廠類幾種了全部產品的建立邏輯，一旦不能正常工做，整個系統都會受到影響，並且當產品類多結構複雜的時候，把全部建立工做放進一個工廠中來，回過後期程序的擴展較爲困難。

經過優缺點的分析，咱們能夠再以下場景中使用簡單工廠模式：

（1）工廠類負責建立的對象較少時；

（2）客戶端只知道傳入工廠類的參數，對於如何建立對象的邏輯沒必要關心時。

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

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

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

增 加了代碼的複雜度，增長了調用層次，增長了內存負擔。因此要注意防止模式的濫用。

 

分享：http://my.oschina.net/leejan97/blog/311843

---

（七）MVVM

MVC

在 iOS 應用中日益增加的重量級視圖控制器的問題。在典型的 MVC 應用裏， 許多 邏輯被放在 View Controller 裏。

它們中的一些確實屬於 View Controller，但更多的是所謂的「表示邏輯（presentation logic）;

爲了避免讓控制器日益增大,便於測試管理,便出現了MVVM.

MVVM:它實際上是一個 MVC 的加強版，並將表示邏輯從 Controller 移出放到一個新的對象裏，即 View Model

在 iOS 上使用 MVVM 的動機,就是讓它能減小 View Controller 的複雜性並使得表示邏輯更易於測試

MVVM-----ViewModel: 它位於 View/Controller 與 Model 之間.

 

http://my.oschina.net/leejan97/blog/311843

 

 

http://www.jianshu.com/p/ab1c7cc0a252