原文連結：http://www.cnblogs.com/dxb123456/p/5479198.html

一  iOS中都有什麼設計模式？

1.代理模式

2.觀察者模式

3.MVC模式

4.單例模式

5.策略模式

6.工廠模式

二  各個設計模式的作用？

（一）代理模式

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

此模式的通用實現中，觀察者註冊自己感興趣的其它物件的狀態變更事件。當狀態發生變化的時候，所有的觀察者都會得到通知。蘋果的推送通知（Push Notification）就是一個此模式的例子。

如果你要遵從MVC模式的概念，你需要讓模型物件和檢視物件在不相互直接引用的情況下通訊。這正是觀察者模式的用武之地。

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

在cocoa框架中的Delegate模式中，委託人往往是框架中的物件（檢視中的控制元件、表檢視神馬的），代理人往往是檢視控制器物件。

在我們這個例子中UITableView是委託人，代理人首先得滿足一個條件：就是在.h檔案中申明它擁有代理資格：

@interface WhateverViewController < UITableViewDelegate >
@end

紅色的表示這個檢視控制器擁有UITableView的代理資格。

其次，在.m檔案中定義委託人可以讓代理人去代替做的事情：

//檢視控制器來代辦應該有多少個節
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return [NSArray count];
}
//檢視控制器來代辦某個節應該有多少行
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return [[NSArray objectAtIndex:section]count];
}
// 檢視控制器來代辦負責每個欄格的外觀
- (UITableViewCell *)tableView:(UITableView *)tableView 
      cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault 
                reuseIdentifier:CellIdentifier] autorelease];
    }
 
    cell.textField.text = [NSArray objectAtIndex:indexPath.row]; 
 
    return cell;
}
//負責當欄格被點選後需要觸發的事件
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    AnotherViewController *anotherViewController = [[AnotherViewController alloc]
                                                                         initWithNibName:@"AnotherView" bundle:nil];
    [self.navigationController pushViewController:anotherViewController];
    [anotherViewController release];
}
// 這個是可選的，檢視控制器勤快我就幫你代辦，不勤快我就可以不幫你辦這事兒，(提供哪些個行可以被編輯)
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath {
    return YES;
}
// 對特定編輯風格進行操作
- (void)tableView:(UITableView *)tableView 
        commitEditingStyle:(UITableViewCellEditingStyle)editingStyle 
        forRowAtIndexPath:(NSIndexPath *)indexPath 
{
    if (editingStyle == UITableViewCellEditingStyleDelete) {
        [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:YES];
    }
    else if (editingStyle == UITableViewCellEditingStyleInsert) {
    }
}
// 可選，對那些被移動欄格作特定操作
- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath *)fromIndexPath 
        toIndexPath:(NSIndexPath *)toIndexPath {
}
// 對那些可以移動的行返回YES
- (BOOL)tableView:(UITableView *)tableView canMoveRowAtIndexPath:(NSIndexPath *)indexPath {
    // 如果不想讓欄格移動，就返回NO
    return YES;
}

 好了，當這個委託人需要辦這些事時，代理人自己就站出來幫忙辦了。這就是ios中的Delegate模式。

二、自定義的delegate模式

@interface A：UIView
id transparendValueDelegate;
@property(nomatic, retain) id transparendValueDelegate;

@end

@implementation A
@synthesize transparendValueDelegate

-(void)Call
{ 
NSString* value = @"你好";
[transparendValueDelegate transparendValue: value];
}

@end


@interface B：UIView

NSString* value;
@end


@implementation B
-(void)transparendValue:(NSString*)fromValue
{
value = fromValue;
NSLog(@"%@ ,我是B",value); 
}
@end

使用時：

A* a = [[A alloc] init];
B* b = [[B alloc] init];
a. transparendValueDelegate = b;//設定A代理委託物件為B
[a Call];

這樣就會輸出:

你好,我是B

 委託模式關鍵就在於一個“被”字。這個B是很被動的，隨時就會被你A Call一下。

三、為什麼會有delegate模式

換句話說，它可以用來解決神馬問題？

當一個類的某些功能需要被別人來實現，但是既不明確是些什麼功能，又不明確誰來實現這些功能的時候，委託模式就可以派上用場。

例如你可以再寫個C類，實現-(void)transparendValue:(NSString*)fromValue {NSLog(@"%@ ,我是C",value); }也是完全可以的。換誰來，只要它實現了這個方法，我就可以委託它來做這個事。

說到底一切都是為了使類之間的耦合性更鬆散。好的程式碼應該對擴充套件開放，對修改關閉。

總結來自http://blog.sina.com.cn/s/blog_b638dc89010192qu.html

（二）觀察者模式

在軟體開發中，無論是那種高階語言中總會伴隨著一些最為常用的設計模式，即便就如iOS開發中與我們打交道最多的無非就是單例模式、觀察者模式和工廠模式了，當然了其他的設定模式也同樣存在在程式設計的很多地方。下面就就讓我們簡單的瞭解下觀察者模式吧!

觀察者模式本質上時一種釋出-訂閱模型,用以消除具有不同行為的物件之間的耦合，通過這一模式，不同物件可以協同工作，同時它們也可以被複用於其他地方Observer從Subject訂閱通知，ConcreteObserver實現重現ObServer並將其過載其update方法。一旦SubJect的例項需要通知Observer任何新的變更，Subject會發送update訊息來通知儲存在其內部類中所註冊的Observer、在ConcreteObserver的update方法的實際實現中，Subject的內部狀態可被取得並進行後續處理。其類圖如下:

觀察者模式.png

由上面我們可以發現觀察者模式無非在是定義物件間的一種一對多的依賴關係，並且當一個物件的狀態發生改變的時候，所有依賴於它的物件都會得到通知且自動更新。即如果Subject允許其他觀察者(實現了觀察者介面的物件)對這個Subject的改變進行請閱，當Subject傳送了變化，那麼Subject會將這個變化傳送給所有的觀察者，觀察者就能對Subject的變化做出更新。其時序圖如下

觀察者模式2.png

通過上面的觀察我們可以發現如果用N個Observer來拓展Subject的行為，這些Observer具有處理儲存在Subject中的資訊的特定實現，這樣也就實現了前面所說的消除不同物件間的耦合的功能了。

那麼瞭解了這些我們可能就會更像瞭解下我們在什麼時候才會去使用觀察者模式呢？

• 當需要將改變通知所有的物件時，而你又不知道這些物件的具體型別
• 改變發生在同一個物件中，並需要改變其他物件將相關的狀態進行更新且不知道有多少個物件。

而同樣的在我們日常的開發中在Cocoa Touch框架中的的兩種經常打交道的技術KVO與通知都實現了觀察者模式，所以下面我們討論的重點也就是基於這兩個方面的。

通知

在之前的博文中曾經簡單的提到過一些通知的基礎使用方法，所以一些基本的使用方法再次就不贅述。言歸正傳，在Cocoa Touch框架中NSNotificationCenter和NSNotification物件實現了一對多的模型。通過NSNotificationCenter可以讓物件之間進行通訊，即便這些物件之間並不認識。下面我們來看下NSNotificationCenter釋出訊息的方法:

   NSNotification  * subjectMessage = [ NSNotification  notificationWithName:@"subjectMessage"  object: self];
    NSNotificationCenter  * notificationCenter = [ NSNotificationCenter  defaultCenter];
    [notificationCenter postNotification:subjectMessage];

通過上面的程式碼我們建立了一個名為subjectMessage的NSNotification物件,然後通過notificationCenter來發布這個訊息。通過向NSNotificationCenter類傳送defaulCenter訊息，可以得到NSNotificationCenter例項的引用。每個程序中只有一個預設的通知中心，所以預設的NSNotificationCenter是個單例物件。如果有其他觀察者定於了其物件的相關事件則可以通過以下的方法來進行操作:

    NSNotificationCenter  * notificationCenter1 = [ NSNotificationCenter  defaultCenter];
    [notificationCenter addObserver: self  selector: @selector(update:) name:@"subjectMessage"  object: nil ];

經過以上步驟我們已經向通知中心註冊了一個事件並且通過selector制定了一個方法update:下面我們可以實現以下這個方法

- (void)update:(NSNotification*)notification{

        if ([[notification name] isEqualToString:@"subjectMessage"]) {
            NSLog(@"%@",@"猴子派來的救兵去哪了？");

        }
}

當然最後如果我們需要對監聽進行銷燬

- (void)dealloc {
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

瞭解過通知之後我們來看一下KVO

KVO是Cocoa提供的一種稱為鍵值觀察的機制，物件可以通過它得到其他物件特定屬性的變更通知。而這個機制是基於NSKeyValueObserving非正式些，Cocoa通過這個協議為所有遵循協議的物件提供了一種自動化的屬性監聽的功能。

雖然通知和KVO都可以對觀察者進行實現，但是他們之間還是略有不同的，由上面的例子我們可以看出通知是由一箇中心物件為所有觀察者提供變更通知，主要是廣義上關注程式事件，而KVO則是被觀察的物件直接想觀察者傳送通知，主要是綁定於特定物件屬性的值。下面我們通過一個簡單的例子來了解下他的一些是使用方法

首先我們有Hero這個模型

@property (nonatomic,copy) NSString * name;
@property (nonatomic,copy) NSString * title;
@property (nonatomic,assign) NSUInteger age;

在控制其中我們將其初始化並賦值

    self.hero = [[Hero alloc] init];
    self.hero.name = @"趙雲";
    self.hero.title = @"將軍";
    self.hero.age = 87;

現在我們的這個物件基本有值了，那麼我們將這個物件的name監聽下他的改變

[self.hero addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld context:nil];

觸發通知並將值改變

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{
    self.hero.name = @"張飛";
}

在制定的回撥函數中，處理收到的更改通知

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context{
    if([keyPath isEqualToString:@"name"])
    {
        NSLog(@"賦值後--%@",self.hero.name);
        NSLog(@"新的值--%@",change[@"new"]);
        NSLog(@"以前的值--%@",change[@"old"]);

    }
}

回撥列印如下:

dayin.png

最後登出觀察者

- (void)dealloc{
    [self.hero removeObserver:self forKeyPath:@"name"];
}

到了這裡觀察者模式中常用的KVO及通知的內容就到這裡，不過要知道這裡談及的只是最基礎的用法，後面我們可能還是有更加深入的探究，或者在後續中可能還會對比iOS中的代理以及Block來探尋下iOS中的訊息傳遞機制，再或者像Swift中的didSet、willSet的屬性監聽的方法，這些都是很好玩的內容，不是麼？

（三）MVC模式

MVC根據角色劃分類，涉及到三個角色：

Model:模型儲存應用程式的資料。

View：檢視是模型的視覺化表示以及使用者互動的控制元件。

Controller:控制器是一個協調所有工作的中介者。它訪問模型中的資料並在檢視中展示它們，同時它們還監聽事件和操作資料。

一個MVC模式的好的實現也就意味著每一個物件都會被劃分到上面所說的組中。

我們可以很好的用下圖來描述通過控制器實現的檢視到模型的互動過程：

模型會把任何資料的變更通知控制器，然後控制器更新檢視資料。檢視物件通知控制器使用者的操作，控制器要麼根據需要來更新模型，要麼檢索任何被請求的資料。

你可能在想為什麼不能僅僅使用控制器，在一個類中實現檢視和模型，這樣貌似更加容易？

所有的這些都歸結於程式碼關注點分離以及複用。在理想的狀態下，檢視應該和模型完全的分離。如果檢視不依賴某個實際的模型，那麼檢視就可以被複用來展示不同模型的資料。

舉個例子來說，如果將來你打算加入電影或者書籍到你的資料庫中，你仍然可以使用同樣的AlbumView去顯示電影和書籍資料。更進一步來說，如果你想建立一個新的與專輯有關聯的工程，你可以很簡單的複用Album類，因為它不依賴任何檢視。這就是MVC的強大之處。

（四）單例模式

單例設計模式確保對於一個給定的類只有一個例項存在，這個例項有一個全域性唯一的訪問點。它通常採用懶載入的方式在第一次用到例項的時候再去建立它。

注意：蘋果大量使用了此模式。例如：[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的這些方法都返回一個單例物件。

你很可能會想為什麼這麼關心是否一個類有多個例項？畢竟程式碼和記憶體都是廉價的，對嗎？ 

有一些情況下，只有一個例項顯得非常合理。舉例來說，你不需要有多個Logger的例項，除非你想去寫多個日誌檔案。或者一個全域性的配置處理類：實現執行緒安全的方式訪問共享例項是容易的，比如一個配置檔案，有好多個類同時修改這個檔案。

（五）策略模式

1.概述

在軟體開發中也常常遇到類似的情況，實現某一個功能有多種演算法或者 策略，我們可以根據環境或者條件的不同選擇不同的演算法或者策略來完成該功能 。如查詢、排序等，一種常用的方法是硬編碼(Hard Coding)在一個類中，如需要提供多種查詢演算法，可以將這些演算法寫到一個類中，在該類中提供多個方法，每一個方法對應一個具體的查詢演算法；當然也可以將這些查詢演算法封裝在一個統一的方法中，通過if…else…或者 case 等條件判斷語句來進行選擇。這兩種實現方法我們都可以稱之為硬編碼，如果需要增加一種新的查詢演算法，需要修改封裝演算法類的原始碼；更換查詢演算法，也需要修改客戶端呼叫程式碼。在這個演算法類中封裝了大量查詢演算法， 該類程式碼將較複雜，維護較為困難。如果我們將這些策略包含在客戶端 ，這種做法更不可取，將導致客戶端程式龐大而且難以維護，如果存在大量可供選擇的演算法時問題將變得更加嚴重。

例子1：一個選單功能能夠根據使用者的“面板”首選項來決定是否採用水平的還是垂直的排列形式。同事可以靈活增加選單那的顯示樣式。

例子2：出行旅遊：我們 可以有幾個策略可以考慮：可以騎自行車，汽車，做火車，飛機。每個策略都可以得到相同的結果，但是它們使用了不同的資源。選擇策略的依據是費用，時間，使用工具還有每種方式的方便程度 。

2.問題

如何讓演算法和物件分開來，使得演算法可以獨立於使用它的客戶而變化？ 

3.解決方案

策略模式： 定 義一系列的演算法,把每一個演算法封裝起來, 並且使它們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化。 也稱為 政策模式 (Policy) 。（ Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it.  ）

策略模式把物件本身和運算規則區分開來，其 功能非常強大，因為這個設計模式本身的核心思想就是面向物件程式設計的多形性的思想。

4.適用性

當存在以下情況時使用Strategy模式

1）• 許多相關的類僅僅是行為有異。 “策略”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統需要動態地在幾種演算法中選擇一種。

2）• 需要使用一個演算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的演算法。當這些變體實現為一個演算法的類層次時 ,可以使用策略模式。

3）• 演算法使用客戶不應該知道的資料。可使用策略模式以避免暴露覆雜的、與演算法相關的資料結構。

4）• 一個類定義了多種行為 , 並且這些行為在這個類的操作中以多個條件語句的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。

5.結構

6.效果

Strategy模式有下面的一些優點：

1) 相關算法系列 

Strategy類層次為Context定義了一系列的可供重用的演算法或行為。 繼承有助於析取出這些演算法中的公共功能。 

2) 提供了可以替換繼承關係的辦法

： 繼承提供了另一種支援多種演算法或行為的方法。你可以直接生成一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編制到 Context中，而將演算法的實現與Context的實現混合起來,從而使Context難以理解、難以維護和難以擴充套件，而且還不能動態地改變演算法。最後你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的演算法或行為。 將演算法封裝在獨立的Strategy類中使得你可以獨立於其Context改變它，使它易於切換、易於理解、易於擴充套件。 

3) 消除了一些if else條件語句

：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件語句來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件語句。含有許多條件語句的程式碼通常意味著需要使用Strategy模式。 

4) 實現的選擇

Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取捨要求從不同策略中進行選擇。

Strategy模式缺點 : 

1)客戶端必須知道所有的策略類，並自行決定使用哪一個策略類

:  本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。 

2 ) Strategy和Context之間的通訊開銷

：無論各個ConcreteStrategy實現的演算法是簡單還是複雜, 它們都共享Strategy定義的介面。因此很可能某些 ConcreteStrategy不會都用到所有通過這個介面傳遞給它們的資訊；簡單的 ConcreteStrategy可能不使用其中的任何資訊！這就意味著有時Context會建立和初始化一些永遠不會用到的引數。如果存在這樣問題 , 那麼將需要在Strategy和Context之間更進行緊密的耦合。 

3 )策略模式將造成產生很多策略類

：可以通過使用享元模式在一定程度上減少物件的數量。 增加了物件的數目 Strategy增加了一個應用中的物件的數目。有時你可以將 Strategy實現為可供各Context共享的無狀態的物件來減少這一開銷。任何其餘的狀態都由 Context維護。Context在每一次對Strategy物件的請求中都將這個狀態傳遞過去。共享的 Strategy不應在各次呼叫之間維護狀態。

7. iOS應用分析

例如，我們在驗證使用者輸入的表單的時候，加入包括電話輸入框的驗證和郵件輸入框的驗證，這兩部分的驗證演算法是不同的，如果把這個演算法看成一個函式，他幾乎有相同的輸入引數和返回引數。我們可以把這個相同的函式可以抽象為基類(InputValidator)的一個方法(bool validateInput(input,error))，然後抽象出兩個具體的策略類：電話驗證類(PhoneValidator)和郵件驗證類(EmailValidator)，他們需要在各自的實現裡面去複寫父類的驗證方法。為了能夠正常的呼叫到驗證類的驗證方法，我們需要自定義一個UITextField的子類CustomTextField，其中有一個InputValidator型別的引用和一個validate方法，該方法裡面呼叫InputValidator的驗證方法，然後在textFieldDidEndEditing代理方法裡面呼叫CustomTextField的validate方法，這樣就不用我們在判斷輸入是否合法的時候通過if else去處理每種邏輯，而且這樣做方便擴充套件，提高可複用性。 

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

（六）工廠模式

工廠模式我的理解是：他就是為了建立物件的

建立物件的時候，我們一般是alloc一個物件，如果需要建立100個這樣的物件，如果是在一個for迴圈中還好說，直接一句alloc就行了，但是事實並不那麼如意，我們可能會在不同的地方去建立這個物件，那麼我們可能需要寫100句alloc 了，但是如果我們在建立物件的時候，需要在這些物件建立完之後，為它的一個屬性新增一個固定的值，比方說都是某某學校的學生，那麼可能有需要多些100行重複的程式碼了，那麼，如果寫一個-(void)createObj方法，把建立物件和學校屬性寫在這個方法裡邊，那麼就是會省事很多，也就是說我們可以alloc 建立物件封裝到一個方法裡邊，直接呼叫這個方法就可以了，這就是簡單工廠方法

程式碼結構如下

Animal 類

@interface Animal :NSObject

@proterty(nonatomic,strong) NSString *name;

-(void)laugh;

@end

Dog類

@interface Dog:Animal

@end

Cat類

@interface Cat:Animal

@end

建立物件的工廠類

.h

@interface AnimalFactory:NSObject

+(Dog *)createDog;

+(Cat *)createCat;

@end

.m

@implementation AnimalFactory

+(Dog *)createDog{

    Dog *dog=[[Dog alloc]init];

    [email protected]“baby”;

    return dog;

}

+(Cat *) createCat{

    Cat *cat=[[Cat alloc]init];

    return cat;

}

Main.m檔案

Dog *dog=[AnimalFactory createDog];

Cat *cat=[AnimalFactory createCat];

這是簡單工廠模式

現在建立100個Dog物件，如果這100個物件寫在程式中的不同地方，按上邊的方法是需要把Dog *dog=[AnimalFactory createDog];這一句話寫在程式中很多不同的地方，那麼現在有一個需求，就是如果需要把這些建立的100個Dog物件全部變成Cat物件，那麼按照剛才的那個做法，就需要在這100句程式碼中把createDog方法變成createCat方法了，這樣做還是很複雜

那麼這個時候用工廠方法模式就能解決這個難題了

工廠方法模式是為每一個要建立的物件所在的類都相應地建立一個工廠

程式碼如下

@interface AnimalFactory:NSObject

-(Animal*)createAnimal;

@end;

Dog工廠類

@interface DogFactory:AnimalFactory;

@implementation DogFactory

-(Animal *)createAnimal{

retrurn [[Dog alloc]init];

}

@end

Cat工廠類

@interface CatFactory:AnimalFactory;

@implementation Cat Factory

-(Animal *)createAnimal

retrurn [[Cat alloc]init];

}

@end

Main.m

AnimalFactory *dogFactory=[[DogFactory alloc]init];

Animal *animal1=[dogFactory createAnimal];

[animal1 laugh];

Animal *animal2=[dogFactory createAnimal];

[animal2 laugh];

…….

Animal *animal100=[dogFactory createAnimal];

[animal100 laugh];

這樣話如果要把100個Dog改為Cat的話，只需要吧DogFactory改為CatFactory就可以了

但是工廠方法也有它的限制：

1.要建立的類必須擁有同一個父類

2.要建立的類在100個不同的地方所呼叫的方法必須一樣

以上這些只是個人感悟，會有一些不足的地方，請大家幫忙改正，嘿嘿