iOS 中的 21 種設計模式

對象創建

原型(Prototype)

使用原型實例指定創建對象的種類,并通過復制這個原型創建新的對象。

NSArray *array = [[NSArray alloc] initWithObjects:@1, nil];

? ?NSArray *array2 = array.copy;

array 就是原型了,array2 以 array 為原型,通過 copy 操作創建了 array2。

當創建的實例非常復雜且耗時,或者新實例和已存在的實例值相同,使用原型模式去復制已經存在的實例效率更高。

工廠方法(Factory Method)

定義創建對象的接口,讓子類決定實例化哪一個類。工廠方法使得類的實例化延遲到其子類。

工廠方法是針對每一種產品提供一個工廠類。通過不同的工廠類來創建不同的產品實例。


+ create():Product 就是工廠方法,ConcreatFactoryA 與 ConcreateFactoryB 就是兩個工廠類,ConcreateProductA 與 ConcreateProductB 就是兩個工廠類對應的產品類,通過不同的工廠生產不同類型的產品,且兩個產品類最終返回的是他們的父類 Product,隱藏了對象的具體類型。工廠方法模式讓創建的對象擁有一組共同的接口,使我們無需關心做了不同類型接口的具體實現,只需要調用 Product 的接口就行。

工廠方法模式的擴展性也很好,新增的產品類并不需要修改客戶端代碼。但每新加一個產品類都需要新建一個工廠類,會造成項目中的類過多。

而在 Cocoa Touch 框架中,以 NSNumber 舉例,將原有的 alloc+init 拆開寫:

id obj1 = [NSNumber alloc];

? ?id obj2 = [NSNumber alloc];

? ?id obj3 = [obj1 initWithBool:YES];

? ?id obj4 = [obj2 initWithChar:'1'];

發現 + alloc 后并非生成了我們期望的類實例,而是一個NSPlacehodlerNumber 的中間對象,后面的 – initWithXXXXX 消息都是發送給這個中間對象,再由它做工廠,生成真的對象。如 obj3 的實際類型為 NSCFBoolean,而 obj4 的實際類型為 NSCFNumber 。

抽象工廠(Abstract Factory)

提供一個創建一系列相關或相互依賴對象的接口,而無需指定它們具體的類。


抽象工廠有一個產品族的概念,Factory1 與 Factory2 是繼承 AbstractFactory 的兩個產品族工廠類, 繼承了父類創建 A,B 兩個產品的方法,不同產品族工廠類會創建不同類型的產品,最終返回了不同的產品族對象,既 ProductA 和 ProductB。

在 Cocoa Touch 框架中,類簇是抽象工廠模式在 iOS 下的一種實現,以 NSArray 舉例,將原有的 alloc+init 拆開寫:

id obj1 = [NSArray alloc]; // __NSPlacehodlerArray *

id obj2 = [NSMutableArray alloc]; ?// __NSPlacehodlerArray *

id obj3 = [obj1 init]; ?// __NSArrayI *

id obj4 = [obj2 init]; ?// __NSArrayM *

發現 + alloc 后并非生成了我們期望的類實例,而是一個NSPlacehodlerArray 的中間對象,后面的 – init 或 – initWithXXXXX 消息都是發送給這個中間對象,再由它做工廠,生成真的對象。這里的 NSArrayI 和 __NSArrayM 分別對應 Immutable 和 Mutable(后面的 I 和 M 的意思)

于是順著思路猜實現,__NSPlacehodlerArray 必定用某種方式存儲了它是由誰 alloc 出來的這個信息,才能在 init 的時候知道要創建的是可變數組還是不可變數組。

抽象工廠將一系列的產品族統一到一起創建,增加產品族很方便,但增加產品很麻煩,需要改動太多的類的接口。

生成器(Builder)

將一個復雜對象的構建與它的表現分離,使得同樣的構建過程可以創建不同的表現。

生成器可以將構建對象的過程分為,客戶 – 指導者 – 生成器 的關系,

CharacterBuilder *characterBuilder = [[StandarCharacterBuilder alloc] init];

? ?ChasingGame *game = [[ChasingGame alloc] init];

? ?Character *player = [chasingGame createPlayer:characterBuilder];

? ?Character *enemy = [chasingGame createEnemy:characterBuilder];

characterBuilder 就是生成器了,而 game 就是指導者。指導者里聲明了創建不同表現的對象的方法。而方法里由生成器 characterBuilder 來構建不同的 Character 類型的對象。

生成器模式將復雜的生成對象的過程交給了生成器去完成,作為客戶的我們只需要根據簡單的接口去生成不同表現的對象。如上述代碼中的 player 以及 enemy。玩家和敵人具體的屬性數值我們不需要去設置,而是交給生成器去設置。

單例(Singleton)

保證一個類僅有一個實例,并提供一個訪問它的全局訪問點。

在 Cocoa Touch 框架中,最常見的使用了單例模式的就是 UIApplication 類了。每個應用程序有且僅有一個 UIApplication 的實例,它由 UIApplicationMain 函數在程序啟動時創建為單例對象,之后,對同一 UIApplication 實例可以通過其 sharedApplication 類方法進行訪問。

單例用來集中管理對類的對象所提供的資源,例如應用程序中需要用集中式的類來協調其服務,這個類就應該生成單一的實例。

單例模式在多線程的應用場合下必須小心使用。如果當唯一實例尚未創建時,有兩個線程同時調用創建方法,那么它們同時沒有檢測到唯一實例的存在,從而同時各自創建了一個實例,這樣就有兩個實例被構造出來,從而違反了單例模式中實例唯一的原則。 解決這個問題的辦法是為指示類是否已經實例化的變量提供一個互斥鎖。

接口適配

適配器(Adapter)

將一個類的接口轉換成客戶希望的另一個接口,適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。

適配器模式分為類適配器模式和對象適配器模式。

上圖是對象適配器模式,Adapter(適配器)遵守了 Target(目標接口)協議,擁有一個 Adaptee(被適配者)的對象 adaptee 的引用,當調用 Adapter 的 request 方法,request 方法里會去調用 adapteee 的 specificRequest 方法。

類適配模式


類適配器模式中適配器和被適配者是繼承關系。request 方法里會去調用 super 的 specificRequest 方法,達到將類的接口轉換成客戶希望的另一個接口。

適配器模式主要應用于“希望復用一些現存的類,但是接口又與復用環境要求不一致的情況”,在遺留代碼復用、類庫遷移等方面非常有用。

橋接(Bridge)

將抽象部分與它的實現部分分離,使它們都可以獨立地變化。

橋接模式是軟件設計模式中最復雜的模式之一,在軟件系統中,某些類型由于自身的邏輯,它具有兩個或多個維度的變化。


毛筆和顏色是兩個維度的變化,可以選擇新建 9 個類去實現不同顏色的不同毛筆,也可以如圖所示,去組合兩個維度。對于客戶端而言,可以針對兩個維度的抽象層編程,在程序運行的時候再動態確認兩個維度的子類,動態組合對象,將兩個獨立變化的維度完全解耦,以便能夠靈活地擴充任一維度而對另一維度不造成任何影響。比如增加一種毛筆并不需要去改動圖中的實現部分,增加一種顏色也不需要去改變抽象部分。(抽象部分是面向我們編程的接口部分,我們繪圖的時候是調用毛筆類的繪圖方法)。

橋接模式可以讓抽象與實現之間不形成綁定關系,在運行時可以切換實現,也將抽象和實現完全解耦,可以獨立擴展。

外觀(Facade)

為系統中的一組接口提供一個統一的接口。外觀頂一個高層接口,讓子系統更易于使用。

外觀模式主要是使用一個外觀類,為復雜的子系統提供一個簡單的接口,而子系統的復雜調用交給外觀類去做。


數據的來源可能是不同數據庫,獲取數據可能非常的復雜,所以使用一個外觀類提供簡單的獲取數據的接口,復雜的操作讓外觀類去做。做到讓子系統更加的易用。

對象去耦

中介者(Mediator)

用一個對象來封裝一系列對象的交互方式,中介者使各對象不需要顯示地相互引用,從而使其耦合松散,而且可以獨立地改變它們之間的交互。

我們開發的程序是由大量的類來組成的,隨著程序功能的不斷增加,類和類之間的依賴關系也跟著趨于復雜,而中介者模式便能解決這個問題,

6 個 VC 類之間的交互可能特別多,如果讓他們相互依賴,然后管理這些 VC 之間的關系是一件非常繁瑣的事情,我們要處理各個 VC 之間的關系,每當一個 VC 要跳轉到另外個 VC,我們需要包含新的 VC 的頭文件。而使用中介者模式,讓 VC 之間的交互變成 VC 和中介者的交互,用中介者來管理多對多的復雜的對象群,降低了各個對象之間的耦合,減少了對象之間邏輯的復雜度,但也可能導致中介者類中的實現過于復雜。

UINavigationController 就是一個中介

視圖控制器的切換都是與 UINavigationController 做交互。由 UINavigationController 去做集中管理。

觀察者(Observer)

定義對象間的一種一對多的依賴關系,當一個對象的狀態發生改變時,所有依賴于它的對象都得到通知并自動更新。

在 Cocoa Touch 框架中通知和 KVO 都實現了觀察者模式。通知是由一個中心對象為所有觀察者提供變更通知,KVO 是被觀察的對象直接向觀察者發送通知。

Subject 的值改變時,通知觀察者 ObserverA,ObserverB,ObserverC,我的數據改變了,依賴我的你們需要更新狀態了。

被觀察者不需要知道有多少個觀察者和觀察者的更新細節,降低被觀察者和觀察者之間的耦合。

抽象集合

組合(Composite)

將對象組合成樹形結構以表示“部分-整體”的層次結構。組合使得用戶對單個對象和組合對象的使用具有一致性。

在 Cocoa Touch 框架中,UIView 被組織成一個組合結構。每個 UIView 都可以將其它 UIView 設置為自己的子視圖,形成一個樹形結構,讓客戶端可以對單個 UIView 或者對 UIView 組合統一對待。

既平移一個 UIView,可以做到平移這一個 UIView 組合,且操作方法與平移單個 UIView 一致。

迭代器(Iterator)

提供一種方法順序訪問一個聚合對象中的各個元素,而又不需要暴露該對象的內部表示,

在 Cocoa Touch 中的 NSEnumerator 就實現了迭代器模式,如以下代碼

NSArray *anArray = @[@"this", @"is", @"a", @"test"];

? ?NSEnumerator *itemEnumerator = [anArray objectEnumerator];

? ?NSString *item;

? ?while (item = [itemEnumerator nextObject]) {

? ? ? ?NSLog(@"%@", item);

? ?}

迭代器分為兩種,上面使用了一個外部迭代器,外部迭代器讓客戶端直接操作迭代過程,如上面代碼就是使用一個 while 循環去迭代。

下面是使用了內部迭代器,客戶端不需要知道實現迭代的方式。

NSArray *anArray = @[@"this", @"is", @"a", @"test"];

? ?NSString *string = @"a";

? ?[anArray enumerateObjectsUsingBlock:^(id ?_Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {

? ? ? ?NSLog(@"%@", obj);

? ? ? ?if ([obj isEqualToString:string]) {

? ? ? ? ? ?*stop = YES;

? ? ? ?}

? ?}];

客戶端不需要手動實現迭代器,只要對每個元素進行處理就行。

行為擴展

訪問者(Visitor)

表示一個作用于某對象結構中的各元素的操作,它讓我們可以在不改變各元素的類的前提下定義作用于這些元素的新操作。

當一個復雜的對象結構包含很多其他的對象,每個對象都有不同的接口,這個時候如果想添加新的接口進行新的操作,就得修改該對象的類,如果每個對象都需要添加新操作,就需要修改更多的類。而訪問者模式就是用來不修改原有類添加新的操作。

訪問者模式涉及兩個關鍵元素,訪問者和被訪問對象。訪問者遵從訪問協議,訪問協議里聲明了訪問方法。訪問方法類似下面

- (void)visitEngine:(NimoEngine *)engine;

- (void)visitWheel:(NimoWheel *)wheel;

訪問者模式流程,直接調用訪問者里的訪問方法,訪問方法里實現了新添加的操作,engine 與 wheel 既被訪問對象,達到了將新操作集中在訪問者里處理的效果。如果再需要新添加一系列對各個元素的操作,只需要再添加一個訪問者類就行。

訪問者能訪問復雜元素里的每一個元素,然后由訪問者對這些元素進行行為擴展。

裝飾(Decorator)

動態地給一個對象添加一些額外的職責。就擴展功能來說,裝飾模式相比生成子類更為靈活。

Category 就是實現了裝飾的設計模式。Category 是 Objective-C 的語言功能,通過它可以給類添加方法的接口與實現,而不必子類化。 從這個設計模式的描述聯想到 Category,就沒什么難理解了。


使多個對象都有機會處理請求,從而避免請求的發送者和接受者之間發生耦合。此模式將這些對象連成一條鏈,并沿著這條鏈傳遞請求,直到有一個對象處理它為止。

Cocoa Touch 中的事件處理流程–響應者鏈就實現了責任鏈模式。以點擊為例,首先通過 hit-test view 的流程找到被點擊的視圖,被點擊的視圖如果不處理點擊事件,則沿著響應者鏈向上回溯,比如給父視圖發消息,讓父視圖去處理,父視圖不處理則繼續沿著響應者鏈向上回溯,直到有對象處理它為止,如果都不處理,則該事件丟棄。

算法封裝

模板方法(Template Method)

定義一個操作中算法的骨架,而將一些步驟延遲到子類中。模板方法使子類可以重定義算法的某些特定步驟而不改變該算法的結構。

模板方法可以提高可擴展性與可復用性,比如 UIView 類中的定制繪圖,UIView 的結構不改變,只是繼承 UIView,再重載 – (void)drawRect:(CGRect)rect

方法。所以 – (void)drawRect:(CGRect)rect 就是模板方法,默認什么都不做或者只是做了部分操作,缺少特性操作,用來給子類選擇重載與實現的方法。


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

舉一個常見的例子,驗證 UITextField 輸入是否有效。有兩個算法分別是驗證郵箱的和驗證電話號碼的。可以通過 if else 這樣的判斷代碼來決定執行哪個算法。也可以通過策略模式,將算法封裝起來,如下圖

Strategy 是這一系列算法的父類,ConcreteStrategyA, B, C。是三種算法,給 Context 對象添加一個 Strategy 類型的屬性,里面存放著 ConcreteStrategyA 或者 B,C。然后 Context 對象就知道去執行哪個算法。也就知道自己需要執行什么策略。

策略模式首先將算法都封裝起來了,易于理解,且易于切換和擴展。

命令(Command)

將請求封裝為一個對象,從而可用不同的請求對客戶進行參數化,對請求排隊或記錄請求日志,以及支持可撤銷的操作。

Cocoa Touch 框架中的 NSInvocation 就是實現了命令模式。

NSMethodSignature*signature = [ViewController instanceMethodSignatureForSelector:@selector(sendMessageWithNumber:WithContent:)];

?//1、創建NSInvocation對象

?NSInvocation*invocation = [NSInvocation invocationWithMethodSignature:signature];

?invocation.target = self;

?//invocation中的方法必須和簽名中的方法一致。

?invocation.selector = @selector(sendMessageWithNumber:WithContent:);

?/*第一個參數:需要給指定方法傳遞的值

? ? ? ? 第一個參數需要接收一個指針,也就是傳遞值的時候需要傳遞地址*/

?//第二個參數:需要給指定方法的第幾個參數傳值

?NSString*number = @"1111";

?//注意:設置參數的索引時不能從0開始,因為0已經被self占用,1已經被_cmd占用

?[invocation setArgument:&number atIndex:2];

?NSString*number2 = @"啊啊啊";

?[invocation setArgument:&number2 atIndex:3];

?//2、調用NSInvocation對象的invoke方法

?//只要調用invocation的invoke方法,就代表需要執行NSInvocation對象中制定對象的指定方法,并且傳遞指定的參數

?[invocation invoke];

將行為封裝成對象,而不是直接觸發行為,因為是對象,所以可以很容易的設計一個命令隊列,也可以方便的記錄進日志里,以及實現行為的撤銷。(因為行為對象可以記錄進日志里,所以可以根據日志得知上一個操作做了什么,從而進行撤銷)。

性能與對象訪問

享元(Flyweight)

利用共享技術有效地支持大量細粒度的對象。

tableViewCell 的重用機制就是實現了享元模式。在要使用一個 Cell 的時候,會先去重用池里看看 tableView 有沒有可以重用的 cell,如果有重用該 cell,沒有創建一個,這就是享元模式。

享元模式主要有兩個關鍵組件,可共享的享元對象和保存它們的享元池。

舉另一個實現例子,畫面上需要顯示 100 個相同的圖案,可以只生成一個包含該圖案 image 的 imageView。其它 99 個只需要去享元池里去拿這個 imageView 實例的信息,然后在頁面里直接繪制圖案,這樣就不需要生成 100 個圖案實例。

享元模式通過共享一部分必須的對象,減少對象的創建,節省大量的內存。

代理(Proxy)

為其它對象提供一種代理以控制對這個對象的訪問。

代理設計模式的英文名是 Proxy pattern,和我們常見的 delegate(委托) 沒關系。

iOS 中常見的代理模式例子為引用計數,當一個復雜對象的多份副本須存在時,代理模式可以結合享元模式以減少內存用量。典型做法是創建一個復雜對象及多個代理者,每個代理者會引用到原本的復雜對象。而作用在代理者的運算會轉送到原本對象。一旦所有的代理者都不存在時,復雜對象會被移除。

當然,上面的代理模式中的代理者什么都沒做,代理對象作為 A 和 C 中間的協調者,可以多做點操作,可以理解為 VPN 中的代理者可以對傳輸數據加密,而 A 和 C 中的代理者,也可以隱藏 C 的信息,做到對 C 的保護。

對象狀態

備忘錄(Memento)

在不破壞封裝的情況下,捕獲一個對象的內部狀態,并在該對象之外保存這個狀態,這樣以后就可將該對象恢復到原先保存的狀態。

Cocoa Touch 框架中歸檔可以實現備忘錄模式,Cocoa 的歸檔是對對象及其屬性還有同其他對象間的關系進行編碼,形成一個文檔,該文檔可以保存于文件系統,也可在進程或網絡間傳輸,最后又可以通過解檔將文檔解碼成與該對象歸檔時狀態一致的對象。

既將對象保存一個備份放置到其它地方,可以隨時使用備份將該對象恢復到原先保存的狀態,用來儲存關鍵對象的關鍵狀態。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,797評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,179評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,628評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,642評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,444評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,948評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,040評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,185評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,717評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,794評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,418評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,414評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,750評論 2 370

推薦閱讀更多精彩內容