iOS設計模式
-
什麼是原型模式?
使用原型例項指定建立物件的種類，並通過複製這個物件建立新的物件。
原型模式其實是通過一個物件為模板建立另外一個可定製的物件，而且不需要知道任何的建立細節。
-
什麼時候使用原型模式?
- 需要建立的物件應該獨立於其型別和建立方式。
- 需要例項化的類是在執行時決定的。
- 不想要與產品層次相對應的工廠層次。
- 不同類的例項間的差異僅是狀態的若干組合。因此複製相應數量的原型比手工例項化更加方便。
- 類不容易建立，比如每個元件可把其他元件作為子節點的組合物件。複製已有的組合物件並對副本進行修改會更加容易。
-
深拷貝與淺拷貝
- 淺拷貝，指標級拷貝，拷貝出的新例項依舊指向源記憶體空間，不論修改原來的例項或者拷貝出的例項，都會影響到另一個（因為指標指向同一塊記憶體）。
- 深拷貝，記憶體級拷貝，會開闢新的記憶體空間，修改原來的例項或者拷貝的例項，另一個不受到影響。
iOS中預設的
-copy是淺拷貝，若要深拷貝，需要遵守<NSCopying>協議，重寫-copyWithZone方法。
二、簡單工廠模式
-
什麼是簡單工廠模式？
簡單工廠模式(Simple Factory Pattern)，又稱為靜態工廠方法(Static Factory Method)模式，在簡單工廠模式中，可以根據引數的不同返回不同類的例項。簡單工廠模式專門定義一個類來負責建立其他類的例項，被建立的例項通常都具有共同的父類。 -
簡單工廠模式的優點
- 將物件的建立和物件本身業務處理分離可以降低系統的耦合度，使得兩者修改起來都相對容易。
- 當你需要什麼，只需要傳入一個正確的引數，就可以獲取你所需要的物件，而無須知道其建立細節。
- 在呼叫工廠類的工廠方法時，由於工廠方法是靜態方法，使用起來很方便，可通過類名直接呼叫，而且只需要傳入一個簡單的引數即可，修改引數時無須修改任何原始碼。
-
簡單工廠模式的缺點
- 簡單工廠模式最大的問題在於工廠類的職責相對過重，增加新的產品需要修改工廠類的判斷邏輯，這一點與開閉原則是相違背的。
三、工廠模式
-
什麼是工廠模式?
定義建立物件的介面，讓子類決定例項化哪一個類。工廠方法使得一個類的例項化延遲到了子類。
-
什麼時候使用工廠模式？
- 編譯時無法準確預期需要建立物件的類。
- 類想要其子類決定在執行時建立什麼型別的例項。
- 類有若干輔助類為其子類，而你想將返回哪個子類這種資訊區域性化。
-
工廠模式的優勢
和直接建立具體物件相比，使用工廠方法建立物件算是最佳的做法。
工廠方法讓客戶端可以要求由工廠方法建立的物件擁有一組共同的行為。
因此，向類層次結構中引入新的具體產品並不需要修改客戶端程式碼，因為返回的任何具體物件的介面跟客戶端一直使用的介面相同。
-
Cocoa Touch中的工廠方法
工廠方法在Cocoa Touch中使用極為廣泛，以NSNumber為例，它提供了很多的建立方法，比如
-numberWithBool和-numberWithInt他們傳入不同型別的引數，獲得NSNumber例項。
四、抽象工廠
-
什麼是抽象工廠?
提供一個建立一系列相關或者相互依賴物件的介面，而無需指定他們的具體類。
如果有多個類共有相同的行為，但實際實現不同，則可能需要某種抽象型別做為他們的父類，抽取其他們共同的行為到父類中。
例如，我們知道普通的披薩餅是什麼樣子，在點餐的時候能預計到端上來的是什麼。當我們說"出去吃披薩"時，這裡的“披薩”其實就是一個抽象型別，定義了披薩餅應該共同具有的特徵。但是，從不同的店我們得到同一披薩餅（比如義大利披薩餅、臘腸披薩餅）的味道大不相同。因為有太多型別的披薩餅，我們簡單地將其叫做“披薩餅”以稱呼這種特定型別的食品。
父類的類方法
-getFactory僅僅只是返回具體的（合適需求的）工廠類。其子類不應該過載這個方法。-getFactory方法根據配置返回一個具體的工廠例項。ofollow,noindex">Demo -
抽象工廠和工廠模式的比較
這兩者在很多方面都很相似，他們都用於相同的目的：建立物件而不讓客戶端知曉建立細節，他們的對比如下：
| 抽象工廠 | 工廠模式 | |
|---|---|---|
| 建立方式 | 物件組合建立抽象產品 | 類繼承建立抽象產品 |
| 建立種類 | 建立多系列產品 | 建立一種產品 |
| 如何擴充套件 | 修改父類的接口才支援新產品 | 子類建立者過載工廠方法以建立新的產品 |
五、建造者(生成器)模式
-
什麼是建造者模式 將一個複雜物件的構建與他的表現分離，使得同樣的構建過程可以建立不同的表現。
它可以將一個產品的內部表象與產品的生成過程分割開來，從而可以使一個建造過程生成具有不同內部表象的產品物件。
如果我們用了建造者模式，那麼使用者只需要指定需要建造的型別就可以得到他們的物件例項，而無需關心建造過程和細節。
在此模式中，除了使用者和其所需的產品，還有兩個重要的角色 Director(指導者)和 Builder(生成器) 。
- Director知道Builder應該建造什麼，以引數向其提供缺少的資訊來建立特定產品。
- Builder是一個抽象介面，聲明瞭一個-build方法，該方法由ConcreBuilder實現，以構造實際的產品，ConcreBuilder有一個-getResult方法，向客戶端返回建造完畢的結果。
-
何時使用建造者模式
- 需要建立涉及各種部件的複雜物件。建立物件的演算法應該獨立於部件的裝配方式。常見例子是構建組合物件。
- 構建過程需要以不同的方式（比如，部件或者表現不同的組合）構建物件。
-
建造者模式和抽象工廠的對比
抽象工廠和建造者模式在 抽象物件建立方有許多相似之處，但是，二者卻大不相同。
- 建造者模式關注的是分步驟建立複雜物件，很多時候，同一型別的物件可以以不同的方式建立。建造者模式在多步建立過程的最後一步返回產品。
- 抽象工廠的重點在於建立簡單或者複雜產品的套件。抽象工廠立即返回產品。
建造者模式 抽象工廠 象的複雜程度 構建複雜物件 需要的步驟 多步建立 建立方式種類 多種方式建立 返回物件的時機 建立過程的最後一步 建立結果 專注一個特定的產品 -
總結
生成器模式能幫助構建涉及部件與表現的各種組合的物件。沒有這一模式，知道構建物件所需細節的Director可能會最終變成一個極其複雜的類。帶有無數用於構建同一類的各種表現的內嵌演算法。而這些演算法本應該獨立於該物件的組成部分以及他們的裝配過程。
六、單例模式
-
何為單例模式
單例模式:保證一個類僅有一個例項，並且提供一個訪問它的全域性訪問點。
單例模式幾乎是設計模式中最簡單的了。它的意圖是使得類的一個物件成為系統中的唯一例項。要實現這一點，可以從客戶端對其進行例項化開始。因此，需要用一種只允許生成物件類唯一例項的機制來“阻止”所有想要生成物件的訪問。
-
何時使用單例模式
- 類只能有一個例項，而且必須從一個為人熟知的訪問點對其進行訪問，（比如工廠方法）。
- 這個唯一的例項只能通過子類化進行擴充套件，而且擴充套件的物件不會破話客戶端程式碼。
-
Objective-C實現單例模式
在OC中，單例模式的實現目前分為兩種：Demo
-
原始實現
遵守<NSCopying>協議重寫-alloc方法和-copy方法,考慮執行緒安全。 -
GCD實現
藉助GCD的dispatch_once實現
-
原始實現
介面適配
七、介面卡
-
何為介面卡模式
介面卡模式，用於連線兩種不同種類的物件，使其毫無問題地協同工作。其思想比較簡單：介面卡實現客戶端所需要的某種介面的行為，同時，它又連線到一個具有（完全）不同介面行為的物件。一邊是客戶端懂得如何使用的目標介面，另一邊是客戶端一無所知的被適配者，介面卡在二者之間。它的主要作用是把被適配者的行為傳遞給管道另一端的客戶端。
定義：將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本介面不相容而不能在一起工作的類可以一起工作了。
-
介面卡分類
-
類介面卡
它是通過類繼承實現的，而Objective-C有著協議（Protocol）這一語言特性，所以在Objective-C中，類可以實現協議，同時又繼承自父類，從而達到C++中多繼承的效果。
要在OC中實現類介面卡，首先需要有定義了客戶端要使用的一套行為的協議，然後用具體的介面卡類來實現這個協議，介面卡類同時也繼承被適配者。
-
物件介面卡
與上面的類介面卡不同，物件介面卡不繼承被適配者，而是組合了一個對他的引用。
-
-
類介面卡與物件介面卡的比較
類介面卡 物件介面卡 只針對單一具體的Adaptee類，把Adaptee適配到target 可以適配多個Adaptee及子類 易於過載Adaptee的行為，以為是通過直接的子類化進行的適配 難以過載，需要藉助子類的物件而非Adaptee本身 只有一個Adaptee物件，無需額外的這鎮間接訪問Adaptee 需要額外的指標間接訪問Adaptee並適配其行為 Adaptee:被適配者
Target:目標介面
-
何時使用介面卡模式
- 已有類的介面與需求不匹配
- 想要一個可複用的類，該類能夠同可能帶有不相容介面的其他類協作。
- 需要適配一個類的幾個不同子類，可是讓每一個子類去子類化一個類適配又不現實，那麼可以使用物件介面卡（委託）來適配其父類的介面。