iOS面試題使用到的設計模式

時間 2019-11-19

標籤 ios 面試使用設計模式欄目 iOS 简体版

原文原文鏈接

iOS中使用到了許多的設計模式，其中包括單例模式、委託模式、觀察者模式、MVC模式等html

下面來分別進行講解：ios

一單例模式

單例模式的意思就是隻有一個實例。單例模式確保某一個類只有一個實例，並且自行實例化並向整個系統提供這個實例。這個類稱爲單例類。objective-c

1.單例模式的要點：算法

　　顯然單例模式的要點有三個；一是某個類只能有一個實例；二是它必須自行建立這個實例；三是它必須自行向整個系統提供這個實例。設計模式

2.單例模式的優勢：併發

　　1.實例控制：Singleton 會阻止其餘對象實例化其本身的 Singleton 對象的副本，從而確保全部對象都訪問惟一實例。

　　2.靈活性：由於類控制了實例化過程，因此類能夠更加靈活修改實例化過程

IOS中的單例模式

　　在objective-c中要實現一個單例類，至少須要作如下四個步驟：
　　一、爲單例對象實現一個靜態實例，並初始化，而後設置成nil，
　　二、實現一個實例構造方法檢查上面聲明的靜態實例是否爲nil，若是是則新建並返回一個本類的實例，
　　三、重寫allocWithZone方法，用來保證其餘人直接使用alloc和init試圖得到一個新實力的時候不產生一個新實例，
　　四、適當實現allocWitheZone，copyWithZone，release和autorelease。

 1 static SurveyRunTimeData *sharedObj = nil; //第一步：靜態實例，並初始化。
 2 @implementation SurveyRunTimeData
 3 + (SurveyRunTimeData*) sharedInstance  //第二步：實例構造檢查靜態實例是否爲nil
 4 {
 5     @synchronized (self)
 6     {
 7         if (sharedObj == nil)
 8         {
 9             [[self alloc] init];
10         }
11     }
12     return sharedObj;
13 }
14 
15 + (id) allocWithZone:(NSZone *)zone //第三步：重寫allocWithZone方法
16 {
17     @synchronized (self) {
18         if (sharedObj == nil) {
19             sharedObj = [super allocWithZone:zone];
20             return sharedObj;
21         }
22     }
23     return nil;
24 }
25 
26 - (id) copyWithZone:(NSZone *)zone //第四步
27 {
28     return self;
29 }
30 
31 - (id) retain
32 {
33     return self;
34 }
35 
36 - (unsigned) retainCount
37 {
38     return UINT_MAX;
39 }
40 
41 - (oneway void) release
42 {
43     
44 }
45 
46 - (id) autorelease
47 {
48     return self;
49 }
50 
51 - (id)init
52 {
53     @synchronized(self) {
54         [super init];//每每放一些要初始化的變量.
55         return self;
56     }
57 }
58 
59 @end

單例model

二委託模式

代理模式是用來用於改變或控制其餘對象，顧名思義就是委託別人去作事情。app

委託的做用有兩個，一個是傳值，一個是傳事件。

1.所謂傳值常常用在B類要把本身的一個數據或者對象傳給A類，讓A類去展現或者處理。（這個做用在兩個View視圖之間傳遞參數的時候特別有用）

2.所謂傳事件就是A類發生了什麼事，把這件事告訴關注本身的人，也就是委託的對象，由委託的對象去考慮發生這個事件後應該作出什麼反映。簡單的說，假如A類發生某個事件，它自己並不出來，而是經過委託delegate的形式，讓它的委託對象B類去處理（固然委託對象B就要實現委託中的方法）。

Delegate 的定義：ide

（1）Delegate 是一個對象，其類型爲 id (anonymous type: 匿名類型)；post

（2） Delegate 的引用一般是一個實例變量（instance variable），命名爲 delegate；ui

（3）Delegate 內所用的方法是訪問模式（Accessors pattern）

Delegate Message 的命名：

發給Delegate的消息一般帶有(should, will, did) 之一。

should：期待delegate返回一個值；

will：表示變化發生以前要作的事情；

did ：表示變化發生以後要作的事情。

Cocoa Touh 的不少類都不一樣程度地用到Delgete。好比： NSTextField， NSTableView。其中 NSTableView 還用到了 Data Source。

其實，Data Source 也是一種委託。 Data Source 減小了 View 與 Model 之間的耦合性。其中， NSAppplication 實現了幾十個委託方法。

Delegate 使用的注意事項：

Delegate 是一個 ID 類型的對象，一樣存在建立和釋放問題。對於Data Source ，只有Data Source的使用者（好比Table View）釋放後， Data Souce 才能被釋放。不然，就會出現crash。由於在table view 獲取數據時，數據已經不見了。

Delegate 可用在多個場景下，好比對象間的數據交互，不一樣視圖之間的行爲交互。若僅僅是數據交互，可實現的方法還有不少。 Delegate 尤爲適用於視圖之間的行爲交互。

委託模式的實現，也能夠經過Block來實現，但僅適合一次性回調執行的代碼。

delegate的優點：

1.很是嚴格的語法。全部將聽到的事件必須是在delegate協議中有清晰的定義。

2.若是delegate中的一個方法沒有實現那麼就會出現編譯警告/錯誤

3.協議必須在controller的做用域範圍內定義

4.在一個應用中的控制流程是可跟蹤的而且是可識別的；

5.在一個控制器中能夠定義定義多個不一樣的協議，每一個協議有不一樣的delegates

6.沒有第三方對象要求保持/監視通訊過程。

7.可以接收調用的協議方法的返回值。這意味着delegate可以提供反饋信息給controller

缺點：

1.須要定義不少代碼：1.協議定義；2.controller的delegate屬性；3.在delegate自己中實現delegate方法定義

2.在釋放代理對象時，須要當心的將delegate改成nil。一旦設定失敗，那麼調用釋放對象的方法將會出現內存crash

3.在一個controller中有多個delegate對象，而且delegate是遵照同一個協議，但仍是很難告訴多個對象同一個事件，不過有可能。

三觀察者模式

在觀察者模式中，一個對象任何狀態的變動都會通知另外的對改變感興趣的對象。這些對象之間不須要知道彼此的存在，這實際上是一種鬆耦合的設計。當某個屬性變化的時候，咱們一般使用這個模式去通知其它對象。

此模式的通用實現中，觀察者註冊本身感興趣的其它對象的狀態變動事件。當狀態發生變化的時候，全部的觀察者都會獲得通知。蘋果的推送通知（ Push Notification ）就是一個此模式的例子。

若是你要聽從 MVC 模式的概念，你須要讓模型對象和視圖對象在不相互直接引用的狀況下通訊。這正是觀察者模式的用武之地。

Cocoa 經過通知（ Notifications ）和 Key-Value Observing(KVO) 來實現觀察者模式。

通知（Notifications）

不要和遠程推送以及本地通知所混淆，通知是一種基於訂閱 - 發佈模式的模型，它讓發佈者能夠給訂閱者發送消息，而且發佈者不須要對訂閱者有任何的瞭解。

通知在蘋果官方被大量的使用。舉例來講，當鍵盤彈出或者隱藏的時候，系統會獨立發送 UIKeyboardWillShowNotification / UIKeyboardWillHideNotification 通知。當你的應用進入後臺運行的時候，系統會發送一個 UIApplicationDidEnterBackgroundNotification 通知。

注意 : 打開 UIApplication.h, 在文件的末尾，你將看到一個由系統發出的超過 20 個通知組成的列表。

使用通知（Notifications）

1 [[NSNotification  CenterdefaultCenter] postNotificationName:@"自定義通知名"  
2                                                     object:self  
3                                                   userInfo:{自定義所帶的參數NSDictionary}];
4 
5 [[NSNotification  CenterdefaultCenter] addObserver:self selector:@selector(響應的方法:) name:@"自定義的要接受通知名" object:nil];   
6 
7 [[NSNotificationCenterdefaultCenter] removeObserver:self];

notification model

在IOS應用開發中有一個」Notification Center「的概念。它是一個單例對象，容許當事件發生時通知一些對象。它容許咱們在低程度耦合的狀況下，知足控制器與一個任意的對象進行通訊的目的。這種模式的基本特徵是爲了讓其餘的對象可以接收到在該controller中發生某種事件而產生的消息，controller用一個key（通知名稱）。這樣對於controller來講是匿名的，其餘的使用一樣的key來註冊了該通知的對象（即觀察者）可以對通知的事件做出反應。

優點：

1.不須要編寫多少代碼，實現比較簡單；

2.對於一個發出的通知，多個對象可以作出反應，即1對多的方式實現簡單

3.controller可以傳遞context對象（dictionary），context對象攜帶了關於發送通知的自定義的信息

缺點：

1.在編譯期不會檢查通知是否可以被觀察者正確的處理；

2.在釋放註冊的對象時，須要在通知中心取消註冊；

3.在調試的時候應用的工做以及控制過程難跟蹤；

4.須要第三方對喜好那個來管理controller與觀察者對象之間的聯繫；

5.controller和觀察者須要提早知道通知名稱、UserInfo dictionary keys。若是這些沒有在工做區間定義，那麼會出現不一樣步的狀況；

6.通知發出後，controller不能從觀察者得到任何的反饋信息。

Key-Value Observing(KVO)模式

在KVO中，一個對象能夠要求在它自身或者其它對象的屬性發送變化的時候獲得通知。若是你對KVO感興趣的話，你能夠更進一步的閱讀這篇文章：Apple’s KVO Programming Guide.

KVO

KVO是一個對象可以觀察另一個對象的屬性的值，而且可以發現值的變化。前面兩種模式更加適合一個controller與任何其餘的對象進行通訊，而 KVO更加適合任何類型的對象偵聽另一個任意對象的改變（這裏也能夠是controller，但通常不是controller）。這是一個對象與另一個對象保持同步的一種方法，即當另一種對象的狀態發生改變時，觀察對象立刻做出反應。它只能用來對屬性做出反應，而不會用來對方法或者動做做出反應。

優勢：

1.可以提供一種簡單的方法實現兩個對象間的同步。例如：model和view之間同步；

2.可以對非咱們建立的對象，即內部對象的狀態改變做出響應，並且不須要改變內部對象（SKD對象）的實現；

3.可以提供觀察的屬性的最新值以及先前值；

4.用key paths來觀察屬性，所以也能夠觀察嵌套對象；

5.完成了對觀察對象的抽象，由於不須要額外的代碼來容許觀察值可以被觀察

缺點：

1.咱們觀察的屬性必須使用strings來定義。所以在編譯器不會出現警告以及檢查；

2.對屬性重構將致使咱們的觀察代碼再也不可用；

3.複雜的「IF」語句要求對象正在觀察多個值。這是由於全部的觀察代碼經過一個方法來指向；

4.當釋放觀察者時不須要移除觀察者。

四 MVC模式

Model-View-Controller ：模型-視圖-控制器，複合模式。

MVC是由數個設計模式結合起來的模式。

M，Model模型：

　　模型持有全部的數據、狀態和程序邏輯。

　　模型沒有注意到視圖和控制器，雖然它提供了操縱和檢索狀態的接口，併發送狀態改變通知給觀察者。

V，View 視圖：

　　視圖用來呈現模型。

　　視圖一般直接從模型中取得它須要顯示的狀態與數據。

C，Controller 控制器：

　　控制器取得用戶的輸入並解讀其對模型的意思。

　　控制器把控制邏輯從視圖中分離，讓模型和視圖之間解耦。經過保持控制器和視圖之間的鬆耦合，設計就更有彈性並且容易擴展。

MVC模式經過創建一個「發佈/訂閱」（publish-subscribe）的機制來分離視圖和模型。發佈－訂閱（publish-subscribe）機制的目標是發佈者，它發出通知時並不需知道誰是它的觀察者。能夠有任意數目的觀察者訂閱並接收通知。MVC模式最重要的是用到了Observer（觀察者模式），正是觀察者模式實現了發佈－訂閱（publish-subscribe）機制，實現了視圖和模型的分離。所以談到MVC模式就必須談到觀察者模式。