對(duì)象創(chuàng)建
原型（Prototype）
使用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并通過復(fù)制這個(gè)原型創(chuàng)建新的對(duì)象。
NSArray *array = [[NSArray alloc] initWithObjects:@1, nil];
? ?NSArray *array2 = array.copy;
array 就是原型了，array2 以 array 為原型，通過 copy 操作創(chuàng)建了 array2。
當(dāng)創(chuàng)建的實(shí)例非常復(fù)雜且耗時(shí)，或者新實(shí)例和已存在的實(shí)例值相同，使用原型模式去復(fù)制已經(jīng)存在的實(shí)例效率更高。
工廠方法（Factory Method）
定義創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類。工廠方法使得類的實(shí)例化延遲到其子類。
工廠方法是針對(duì)每一種產(chǎn)品提供一個(gè)工廠類。通過不同的工廠類來創(chuàng)建不同的產(chǎn)品實(shí)例。
+ create():Product 就是工廠方法，ConcreatFactoryA 與 ConcreateFactoryB 就是兩個(gè)工廠類，ConcreateProductA 與 ConcreateProductB 就是兩個(gè)工廠類對(duì)應(yīng)的產(chǎn)品類，通過不同的工廠生產(chǎn)不同類型的產(chǎn)品，且兩個(gè)產(chǎn)品類最終返回的是他們的父類 Product，隱藏了對(duì)象的具體類型。工廠方法模式讓創(chuàng)建的對(duì)象擁有一組共同的接口，使我們無需關(guān)心做了不同類型接口的具體實(shí)現(xiàn)，只需要調(diào)用 Product 的接口就行。
工廠方法模式的擴(kuò)展性也很好，新增的產(chǎn)品類并不需要修改客戶端代碼。但每新加一個(gè)產(chǎn)品類都需要新建一個(gè)工廠類，會(huì)造成項(xiàng)目中的類過多。
而在 Cocoa Touch 框架中，以 NSNumber 舉例，將原有的 alloc+init 拆開寫：
id obj1 = [NSNumber alloc];
? ?id obj2 = [NSNumber alloc];
? ?id obj3 = [obj1 initWithBool:YES];
? ?id obj4 = [obj2 initWithChar:'1'];
發(fā)現(xiàn) + alloc 后并非生成了我們期望的類實(shí)例，而是一個(gè)NSPlacehodlerNumber 的中間對(duì)象，后面的 – initWithXXXXX 消息都是發(fā)送給這個(gè)中間對(duì)象，再由它做工廠，生成真的對(duì)象。如 obj3 的實(shí)際類型為 NSCFBoolean，而 obj4 的實(shí)際類型為 NSCFNumber 。
抽象工廠（Abstract Factory）
提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無需指定它們具體的類。
抽象工廠有一個(gè)產(chǎn)品族的概念，F(xiàn)actory1 與 Factory2 是繼承 AbstractFactory 的兩個(gè)產(chǎn)品族工廠類， 繼承了父類創(chuàng)建 A，B 兩個(gè)產(chǎn)品的方法，不同產(chǎn)品族工廠類會(huì)創(chuàng)建不同類型的產(chǎn)品，最終返回了不同的產(chǎn)品族對(duì)象，既 ProductA 和 ProductB。
在 Cocoa Touch 框架中，類簇是抽象工廠模式在 iOS 下的一種實(shí)現(xiàn)，以 NSArray 舉例，將原有的 alloc+init 拆開寫：
id obj1 = [NSArray alloc]; // __NSPlacehodlerArray *
id obj2 = [NSMutableArray alloc]; ?// __NSPlacehodlerArray *
id obj3 = [obj1 init]; ?// __NSArrayI *
id obj4 = [obj2 init]; ?// __NSArrayM *
發(fā)現(xiàn) + alloc 后并非生成了我們期望的類實(shí)例，而是一個(gè)NSPlacehodlerArray 的中間對(duì)象，后面的 – init 或 – initWithXXXXX 消息都是發(fā)送給這個(gè)中間對(duì)象，再由它做工廠，生成真的對(duì)象。這里的 NSArrayI 和 __NSArrayM 分別對(duì)應(yīng) Immutable 和 Mutable（后面的 I 和 M 的意思）
于是順著思路猜實(shí)現(xiàn)，__NSPlacehodlerArray 必定用某種方式存儲(chǔ)了它是由誰 alloc 出來的這個(gè)信息，才能在 init 的時(shí)候知道要?jiǎng)?chuàng)建的是可變數(shù)組還是不可變數(shù)組。
抽象工廠將一系列的產(chǎn)品族統(tǒng)一到一起創(chuàng)建，增加產(chǎn)品族很方便，但增加產(chǎn)品很麻煩，需要改動(dòng)太多的類的接口。
生成器（Builder）
將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表現(xiàn)分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表現(xiàn)。
生成器可以將構(gòu)建對(duì)象的過程分為，客戶 – 指導(dǎo)者 – 生成器 的關(guān)系，
CharacterBuilder *characterBuilder = [[StandarCharacterBuilder alloc] init];
? ?ChasingGame *game = [[ChasingGame alloc] init];
? ?Character *player = [chasingGame createPlayer:characterBuilder];
? ?Character *enemy = [chasingGame createEnemy:characterBuilder];
characterBuilder 就是生成器了，而 game 就是指導(dǎo)者。指導(dǎo)者里聲明了創(chuàng)建不同表現(xiàn)的對(duì)象的方法。而方法里由生成器 characterBuilder 來構(gòu)建不同的 Character 類型的對(duì)象。
生成器模式將復(fù)雜的生成對(duì)象的過程交給了生成器去完成，作為客戶的我們只需要根據(jù)簡(jiǎn)單的接口去生成不同表現(xiàn)的對(duì)象。如上述代碼中的 player 以及 enemy。玩家和敵人具體的屬性數(shù)值我們不需要去設(shè)置，而是交給生成器去設(shè)置。
單例（Singleton）
保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。
在 Cocoa Touch 框架中，最常見的使用了單例模式的就是 UIApplication 類了。每個(gè)應(yīng)用程序有且僅有一個(gè) UIApplication 的實(shí)例，它由 UIApplicationMain 函數(shù)在程序啟動(dòng)時(shí)創(chuàng)建為單例對(duì)象，之后，對(duì)同一 UIApplication 實(shí)例可以通過其 sharedApplication 類方法進(jìn)行訪問。
單例用來集中管理對(duì)類的對(duì)象所提供的資源，例如應(yīng)用程序中需要用集中式的類來協(xié)調(diào)其服務(wù)，這個(gè)類就應(yīng)該生成單一的實(shí)例。
單例模式在多線程的應(yīng)用場(chǎng)合下必須小心使用。如果當(dāng)唯一實(shí)例尚未創(chuàng)建時(shí)，有兩個(gè)線程同時(shí)調(diào)用創(chuàng)建方法，那么它們同時(shí)沒有檢測(cè)到唯一實(shí)例的存在，從而同時(shí)各自創(chuàng)建了一個(gè)實(shí)例，這樣就有兩個(gè)實(shí)例被構(gòu)造出來，從而違反了單例模式中實(shí)例唯一的原則。 解決這個(gè)問題的辦法是為指示類是否已經(jīng)實(shí)例化的變量提供一個(gè)互斥鎖。
接口適配
適配器（Adapter）
將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另一個(gè)接口，適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
適配器模式分為類適配器模式和對(duì)象適配器模式。
上圖是對(duì)象適配器模式，Adapter（適配器）遵守了 Target（目標(biāo)接口）協(xié)議，擁有一個(gè) Adaptee（被適配者）的對(duì)象 adaptee 的引用，當(dāng)調(diào)用 Adapter 的 request 方法，request 方法里會(huì)去調(diào)用 adapteee 的 specificRequest 方法。
類適配模式
類適配器模式中適配器和被適配者是繼承關(guān)系。request 方法里會(huì)去調(diào)用 super 的 specificRequest 方法，達(dá)到將類的接口轉(zhuǎn)換成客戶希望的另一個(gè)接口。
適配器模式主要應(yīng)用于“希望復(fù)用一些現(xiàn)存的類，但是接口又與復(fù)用環(huán)境要求不一致的情況”，在遺留代碼復(fù)用、類庫遷移等方面非常有用。
橋接（Bridge）
將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。
橋接模式是軟件設(shè)計(jì)模式中最復(fù)雜的模式之一，在軟件系統(tǒng)中，某些類型由于自身的邏輯，它具有兩個(gè)或多個(gè)維度的變化。
毛筆和顏色是兩個(gè)維度的變化，可以選擇新建 9 個(gè)類去實(shí)現(xiàn)不同顏色的不同毛筆，也可以如圖所示，去組合兩個(gè)維度。對(duì)于客戶端而言，可以針對(duì)兩個(gè)維度的抽象層編程，在程序運(yùn)行的時(shí)候再動(dòng)態(tài)確認(rèn)兩個(gè)維度的子類，動(dòng)態(tài)組合對(duì)象，將兩個(gè)獨(dú)立變化的維度完全解耦，以便能夠靈活地?cái)U(kuò)充任一維度而對(duì)另一維度不造成任何影響。比如增加一種毛筆并不需要去改動(dòng)圖中的實(shí)現(xiàn)部分，增加一種顏色也不需要去改變抽象部分。（抽象部分是面向我們編程的接口部分，我們繪圖的時(shí)候是調(diào)用毛筆類的繪圖方法）。
橋接模式可以讓抽象與實(shí)現(xiàn)之間不形成綁定關(guān)系，在運(yùn)行時(shí)可以切換實(shí)現(xiàn)，也將抽象和實(shí)現(xiàn)完全解耦，可以獨(dú)立擴(kuò)展。
外觀（Facade）
為系統(tǒng)中的一組接口提供一個(gè)統(tǒng)一的接口。外觀頂一個(gè)高層接口，讓子系統(tǒng)更易于使用。
外觀模式主要是使用一個(gè)外觀類，為復(fù)雜的子系統(tǒng)提供一個(gè)簡(jiǎn)單的接口，而子系統(tǒng)的復(fù)雜調(diào)用交給外觀類去做。
數(shù)據(jù)的來源可能是不同數(shù)據(jù)庫，獲取數(shù)據(jù)可能非常的復(fù)雜，所以使用一個(gè)外觀類提供簡(jiǎn)單的獲取數(shù)據(jù)的接口，復(fù)雜的操作讓外觀類去做。做到讓子系統(tǒng)更加的易用。
對(duì)象去耦
中介者（Mediator）
用一個(gè)對(duì)象來封裝一系列對(duì)象的交互方式，中介者使各對(duì)象不需要顯示地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。
我們開發(fā)的程序是由大量的類來組成的，隨著程序功能的不斷增加，類和類之間的依賴關(guān)系也跟著趨于復(fù)雜，而中介者模式便能解決這個(gè)問題，
6 個(gè) VC 類之間的交互可能特別多，如果讓他們相互依賴，然后管理這些 VC 之間的關(guān)系是一件非常繁瑣的事情，我們要處理各個(gè) VC 之間的關(guān)系，每當(dāng)一個(gè) VC 要跳轉(zhuǎn)到另外個(gè) VC，我們需要包含新的 VC 的頭文件。而使用中介者模式，讓 VC 之間的交互變成 VC 和中介者的交互，用中介者來管理多對(duì)多的復(fù)雜的對(duì)象群，降低了各個(gè)對(duì)象之間的耦合，減少了對(duì)象之間邏輯的復(fù)雜度，但也可能導(dǎo)致中介者類中的實(shí)現(xiàn)過于復(fù)雜。
UINavigationController 就是一個(gè)中介
視圖控制器的切換都是與 UINavigationController 做交互。由 UINavigationController 去做集中管理。
觀察者（Observer）
定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并自動(dòng)更新。
在 Cocoa Touch 框架中通知和 KVO 都實(shí)現(xiàn)了觀察者模式。通知是由一個(gè)中心對(duì)象為所有觀察者提供變更通知，KVO 是被觀察的對(duì)象直接向觀察者發(fā)送通知。
Subject 的值改變時(shí)，通知觀察者 ObserverA，ObserverB，ObserverC，我的數(shù)據(jù)改變了，依賴我的你們需要更新狀態(tài)了。
被觀察者不需要知道有多少個(gè)觀察者和觀察者的更新細(xì)節(jié)，降低被觀察者和觀察者之間的耦合。
抽象集合
組合（Composite）
將對(duì)象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。組合使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。
在 Cocoa Touch 框架中，UIView 被組織成一個(gè)組合結(jié)構(gòu)。每個(gè) UIView 都可以將其它 UIView 設(shè)置為自己的子視圖，形成一個(gè)樹形結(jié)構(gòu)，讓客戶端可以對(duì)單個(gè) UIView 或者對(duì) UIView 組合統(tǒng)一對(duì)待。
既平移一個(gè) UIView，可以做到平移這一個(gè) UIView 組合，且操作方法與平移單個(gè) UIView 一致。
迭代器（Iterator）
提供一種方法順序訪問一個(gè)聚合對(duì)象中的各個(gè)元素，而又不需要暴露該對(duì)象的內(nèi)部表示，
在 Cocoa Touch 中的 NSEnumerator 就實(shí)現(xiàn)了迭代器模式，如以下代碼
NSArray *anArray = @[@"this", @"is", @"a", @"test"];
? ?NSEnumerator *itemEnumerator = [anArray objectEnumerator];
? ?NSString *item;
? ?while (item = [itemEnumerator nextObject]) {
? ? ? ?NSLog(@"%@", item);
? ?}
迭代器分為兩種，上面使用了一個(gè)外部迭代器，外部迭代器讓客戶端直接操作迭代過程，如上面代碼就是使用一個(gè) while 循環(huán)去迭代。
下面是使用了內(nèi)部迭代器，客戶端不需要知道實(shí)現(xiàn)迭代的方式。
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;
? ? ? ?}
? ?}];
客戶端不需要手動(dòng)實(shí)現(xiàn)迭代器，只要對(duì)每個(gè)元素進(jìn)行處理就行。
行為擴(kuò)展
訪問者（Visitor）
表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作，它讓我們可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
當(dāng)一個(gè)復(fù)雜的對(duì)象結(jié)構(gòu)包含很多其他的對(duì)象，每個(gè)對(duì)象都有不同的接口，這個(gè)時(shí)候如果想添加新的接口進(jìn)行新的操作，就得修改該對(duì)象的類，如果每個(gè)對(duì)象都需要添加新操作，就需要修改更多的類。而訪問者模式就是用來不修改原有類添加新的操作。
訪問者模式涉及兩個(gè)關(guān)鍵元素，訪問者和被訪問對(duì)象。訪問者遵從訪問協(xié)議，訪問協(xié)議里聲明了訪問方法。訪問方法類似下面
- (void)visitEngine:(NimoEngine *)engine;
- (void)visitWheel:(NimoWheel *)wheel;
訪問者模式流程，直接調(diào)用訪問者里的訪問方法，訪問方法里實(shí)現(xiàn)了新添加的操作，engine 與 wheel 既被訪問對(duì)象，達(dá)到了將新操作集中在訪問者里處理的效果。如果再需要新添加一系列對(duì)各個(gè)元素的操作，只需要再添加一個(gè)訪問者類就行。
訪問者能訪問復(fù)雜元素里的每一個(gè)元素，然后由訪問者對(duì)這些元素進(jìn)行行為擴(kuò)展。
裝飾（Decorator）
動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就擴(kuò)展功能來說，裝飾模式相比生成子類更為靈活。
Category 就是實(shí)現(xiàn)了裝飾的設(shè)計(jì)模式。Category 是 Objective-C 的語言功能，通過它可以給類添加方法的接口與實(shí)現(xiàn)，而不必子類化。 從這個(gè)設(shè)計(jì)模式的描述聯(lián)想到 Category，就沒什么難理解了。
使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免請(qǐng)求的發(fā)送者和接受者之間發(fā)生耦合。此模式將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞請(qǐng)求，直到有一個(gè)對(duì)象處理它為止。
Cocoa Touch 中的事件處理流程–響應(yīng)者鏈就實(shí)現(xiàn)了責(zé)任鏈模式。以點(diǎn)擊為例，首先通過 hit-test view 的流程找到被點(diǎn)擊的視圖，被點(diǎn)擊的視圖如果不處理點(diǎn)擊事件，則沿著響應(yīng)者鏈向上回溯，比如給父視圖發(fā)消息，讓父視圖去處理，父視圖不處理則繼續(xù)沿著響應(yīng)者鏈向上回溯，直到有對(duì)象處理它為止，如果都不處理，則該事件丟棄。
算法封裝
模板方法（Template Method）
定義一個(gè)操作中算法的骨架，而將一些步驟延遲到子類中。模板方法使子類可以重定義算法的某些特定步驟而不改變?cè)撍惴ǖ慕Y(jié)構(gòu)。
模板方法可以提高可擴(kuò)展性與可復(fù)用性，比如 UIView 類中的定制繪圖,UIView 的結(jié)構(gòu)不改變，只是繼承 UIView,再重載 – (void)drawRect:(CGRect)rect
方法。所以 – (void)drawRect:(CGRect)rect 就是模板方法，默認(rèn)什么都不做或者只是做了部分操作，缺少特性操作，用來給子類選擇重載與實(shí)現(xiàn)的方法。
定義一系列算法，把它們一個(gè)個(gè)封裝起來，并且使它們可相互替換。本模式使得算法可獨(dú)立于使用它的客戶而變化。
舉一個(gè)常見的例子，驗(yàn)證 UITextField 輸入是否有效。有兩個(gè)算法分別是驗(yàn)證郵箱的和驗(yàn)證電話號(hào)碼的?？梢酝ㄟ^ if else 這樣的判斷代碼來決定執(zhí)行哪個(gè)算法。也可以通過策略模式，將算法封裝起來，如下圖
Strategy 是這一系列算法的父類，ConcreteStrategyA, B, C。是三種算法，給 Context 對(duì)象添加一個(gè) Strategy 類型的屬性，里面存放著 ConcreteStrategyA 或者 B，C。然后 Context 對(duì)象就知道去執(zhí)行哪個(gè)算法。也就知道自己需要執(zhí)行什么策略。
策略模式首先將算法都封裝起來了，易于理解，且易于切換和擴(kuò)展。
命令（Command）
將請(qǐng)求封裝為一個(gè)對(duì)象，從而可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化，對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可撤銷的操作。
Cocoa Touch 框架中的 NSInvocation 就是實(shí)現(xiàn)了命令模式。
NSMethodSignature*signature = [ViewController instanceMethodSignatureForSelector:@selector(sendMessageWithNumber:WithContent:)];
?//1、創(chuàng)建NSInvocation對(duì)象
?NSInvocation*invocation = [NSInvocation invocationWithMethodSignature:signature];
?invocation.target = self;
?//invocation中的方法必須和簽名中的方法一致。
?invocation.selector = @selector(sendMessageWithNumber:WithContent:);
?/*第一個(gè)參數(shù)：需要給指定方法傳遞的值
? ? ? ? 第一個(gè)參數(shù)需要接收一個(gè)指針，也就是傳遞值的時(shí)候需要傳遞地址*/
?//第二個(gè)參數(shù)：需要給指定方法的第幾個(gè)參數(shù)傳值
?NSString*number = @"1111";
?//注意：設(shè)置參數(shù)的索引時(shí)不能從0開始，因?yàn)?已經(jīng)被self占用，1已經(jīng)被_cmd占用
?[invocation setArgument:&number atIndex:2];
?NSString*number2 = @"啊啊啊";
?[invocation setArgument:&number2 atIndex:3];
?//2、調(diào)用NSInvocation對(duì)象的invoke方法
?//只要調(diào)用invocation的invoke方法，就代表需要執(zhí)行NSInvocation對(duì)象中制定對(duì)象的指定方法，并且傳遞指定的參數(shù)
?[invocation invoke];
將行為封裝成對(duì)象，而不是直接觸發(fā)行為，因?yàn)槭菍?duì)象，所以可以很容易的設(shè)計(jì)一個(gè)命令隊(duì)列，也可以方便的記錄進(jìn)日志里，以及實(shí)現(xiàn)行為的撤銷。（因?yàn)樾袨閷?duì)象可以記錄進(jìn)日志里，所以可以根據(jù)日志得知上一個(gè)操作做了什么，從而進(jìn)行撤銷）。
性能與對(duì)象訪問
享元（Flyweight）
利用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。
tableViewCell 的重用機(jī)制就是實(shí)現(xiàn)了享元模式。在要使用一個(gè) Cell 的時(shí)候，會(huì)先去重用池里看看 tableView 有沒有可以重用的 cell，如果有重用該 cell，沒有創(chuàng)建一個(gè)，這就是享元模式。
享元模式主要有兩個(gè)關(guān)鍵組件，可共享的享元對(duì)象和保存它們的享元池。
舉另一個(gè)實(shí)現(xiàn)例子，畫面上需要顯示 100 個(gè)相同的圖案，可以只生成一個(gè)包含該圖案 image 的 imageView。其它 99 個(gè)只需要去享元池里去拿這個(gè) imageView 實(shí)例的信息，然后在頁面里直接繪制圖案，這樣就不需要生成 100 個(gè)圖案實(shí)例。
享元模式通過共享一部分必須的對(duì)象，減少對(duì)象的創(chuàng)建，節(jié)省大量的內(nèi)存。
代理（Proxy）
為其它對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問。
代理設(shè)計(jì)模式的英文名是 Proxy pattern，和我們常見的 delegate（委托） 沒關(guān)系。
iOS 中常見的代理模式例子為引用計(jì)數(shù)，當(dāng)一個(gè)復(fù)雜對(duì)象的多份副本須存在時(shí)，代理模式可以結(jié)合享元模式以減少內(nèi)存用量。典型做法是創(chuàng)建一個(gè)復(fù)雜對(duì)象及多個(gè)代理者，每個(gè)代理者會(huì)引用到原本的復(fù)雜對(duì)象。而作用在代理者的運(yùn)算會(huì)轉(zhuǎn)送到原本對(duì)象。一旦所有的代理者都不存在時(shí)，復(fù)雜對(duì)象會(huì)被移除。
當(dāng)然，上面的代理模式中的代理者什么都沒做，代理對(duì)象作為 A 和 C 中間的協(xié)調(diào)者，可以多做點(diǎn)操作，可以理解為 VPN 中的代理者可以對(duì)傳輸數(shù)據(jù)加密，而 A 和 C 中的代理者，也可以隱藏 C 的信息，做到對(duì) C 的保護(hù)。
對(duì)象狀態(tài)
備忘錄（Memento）
在不破壞封裝的情況下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)，這樣以后就可將該對(duì)象恢復(fù)到原先保存的狀態(tài)。
Cocoa Touch 框架中歸檔可以實(shí)現(xiàn)備忘錄模式，Cocoa 的歸檔是對(duì)對(duì)象及其屬性還有同其他對(duì)象間的關(guān)系進(jìn)行編碼，形成一個(gè)文檔，該文檔可以保存于文件系統(tǒng)，也可在進(jìn)程或網(wǎng)絡(luò)間傳輸，最后又可以通過解檔將文檔解碼成與該對(duì)象歸檔時(shí)狀態(tài)一致的對(duì)象。
既將對(duì)象保存一個(gè)備份放置到其它地方，可以隨時(shí)使用備份將該對(duì)象恢復(fù)到原先保存的狀態(tài)，用來儲(chǔ)存關(guān)鍵對(duì)象的關(guān)鍵狀態(tài)。
