<1>適配器模式

1. 何為適配器模式？
   適配器模式將一個(gè)類(lèi)的接口適配成用戶所期待的。一個(gè)適配器通常允許因?yàn)榻涌诓患嫒荻荒芤黄鸸ぷ鞯念?lèi)能夠在一起工作，做法是將類(lèi)自己的接口包裹在一個(gè)已存在的類(lèi)中。（聯(lián)想一下現(xiàn)實(shí)生活中的各類(lèi)適配，就比較容易理解了）

2. 如何使用適配器模式？

   以下情況比較適合使用 Adapter 模式：

   • 當(dāng)你想使用一個(gè)已經(jīng)存在的類(lèi)，而它的接口不符合你的需求；
   • 你想創(chuàng)建一個(gè)可以復(fù)用的類(lèi)，該類(lèi)可以與其他不相關(guān)的類(lèi)或不可預(yù)見(jiàn)的類(lèi)協(xié)同工作；
   • 你想使用一些已經(jīng)存在的子類(lèi)，但是不可能對(duì)每一個(gè)都進(jìn)行子類(lèi)化以匹配它們的接口，對(duì)象適配器可以適配它的父親接口。

3. 適配器模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：降低數(shù)據(jù)層和視圖層（對(duì)象）的耦合度，使之使用更加廣泛，適應(yīng)復(fù)雜多變的變化。
   缺點(diǎn)：降低了可讀性，代碼量增加，對(duì)于不理解這種模式的人來(lái)說(shuō)比較難看懂。

4.github示例代碼 ios設(shè)計(jì)模式之適配器模式

<2>策略模式

1. 何為策略模式？
   策略模式定義了一系列的算法，并將每一個(gè)算法封裝起來(lái)，而且使它們還可以相互替換。策略模式讓算法獨(dú)立于使用它的客戶而獨(dú)立變化。

2. 如何使用策略模式？
   在有多種算法相似的情況下，使用 if...else 所帶來(lái)的復(fù)雜和難以維護(hù)。

   • 如果在一個(gè)系統(tǒng)里面有許多類(lèi)，它們之間的區(qū)別僅在于它們的行為，那么使用策略模式可以動(dòng)態(tài)地讓一個(gè)對(duì)象在許多行為中選擇一種行為。
   • 一個(gè)系統(tǒng)需要?jiǎng)討B(tài)地在幾種算法中選擇一種。
   • 如果一個(gè)對(duì)象有很多的行為，如果不用恰當(dāng)?shù)哪Ｊ?，這些行為就只好使用多重的條件選擇語(yǔ)句來(lái)實(shí)現(xiàn)。
   • 注意事項(xiàng)：如果一個(gè)系統(tǒng)的策略多于四個(gè)，就需要考慮使用混合模式，解決策略類(lèi)膨脹的問(wèn)題。

3. 策略模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：簡(jiǎn)化操作，提高代碼維護(hù)性。算法可以自由切換，避免使用多重條件判斷，擴(kuò)展性良好。
   缺點(diǎn)：在使用之前就要確定使用某種策略，而不是動(dòng)態(tài)的選擇策略。策略類(lèi)會(huì)增多，所有策略類(lèi)都需要對(duì)外暴露。

4. github示例代碼ios設(shè)計(jì)模式之策略模式

<3>觀察者模式

1. 何為觀察者模式？
   當(dāng)對(duì)象間存在一對(duì)多關(guān)系時(shí)，則使用觀察者模式（Observer Pattern）。比如，當(dāng)一個(gè)對(duì)象被修改時(shí)，則會(huì)自動(dòng)通知它的依賴(lài)對(duì)象。觀察者模式屬于行為型模式。
2. 如何使用觀察者模式？
   一個(gè)對(duì)象狀態(tài)改變給其他對(duì)象通知的問(wèn)題，而且要考慮到易用和低耦合，保證高度的協(xié)作。一個(gè)對(duì)象（目標(biāo)對(duì)象）的狀態(tài)發(fā)生改變，所有的依賴(lài)對(duì)象（觀察者對(duì)象）都將得到通知，進(jìn)行廣播通知。
3. 觀察者模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：

• 觀察者和被觀察者是抽象耦合的。
• 建立一套觸發(fā)機(jī)制。

缺點(diǎn)：

• 如果一個(gè)被觀察者對(duì)象有很多的直接和間接的觀察者的話，將所有的觀察者都通知到會(huì)花費(fèi)很多時(shí)間。
• 如果在觀察者和觀察目標(biāo)之間有循環(huán)依賴(lài)的話，觀察目標(biāo)會(huì)觸發(fā)它們之間進(jìn)行循環(huán)調(diào)用，可能導(dǎo)致系統(tǒng)崩潰。
• 觀察者模式?jīng)]有相應(yīng)的機(jī)制讓觀察者知道所觀察的目標(biāo)對(duì)象是怎么發(fā)生變化的，而僅僅只是知道觀察目標(biāo)發(fā)生了變化。

4. gitHub示例代碼
   iOS設(shè)計(jì)模式之觀察者模式

5. 設(shè)計(jì)模型圖（在敲代碼的時(shí)候要多想想這個(gè)模型圖）

   觀察者模型圖.png

<4>原型/外觀模式

1. 何為原型/外觀模式？
   原型模式：（Prototype Pattern）用于創(chuàng)建重復(fù)的對(duì)象，同時(shí)又能保證性能。這種類(lèi)型的設(shè)計(jì)模式屬于創(chuàng)建型模式，它提供了一種創(chuàng)建對(duì)象的最佳方式。這種模式是實(shí)現(xiàn)了一個(gè)原型接口，該接口用于創(chuàng)建當(dāng)前對(duì)象的克隆。當(dāng)直接創(chuàng)建對(duì)象的代價(jià)比較大時(shí)，則采用這種模式。
   外觀模式：（Facade Pattern）隱藏系統(tǒng)的復(fù)雜性，并向客戶端提供了一個(gè)客戶端可以訪問(wèn)系統(tǒng)的接口。這種類(lèi)型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它向現(xiàn)有的系統(tǒng)添加一個(gè)接口，來(lái)隱藏系統(tǒng)的復(fù)雜性。
   這種模式涉及到一個(gè)單一的類(lèi)，該類(lèi)提供了客戶端請(qǐng)求的簡(jiǎn)化方法和對(duì)現(xiàn)有系統(tǒng)類(lèi)方法的委托調(diào)用。
2. 如何使用原型/外觀模式？
   原型模式：

• 當(dāng)一個(gè)系統(tǒng)應(yīng)該獨(dú)立于它的產(chǎn)品創(chuàng)建，構(gòu)成和表示時(shí)。
• 當(dāng)要實(shí)例化的類(lèi)是在運(yùn)行時(shí)刻指定時(shí)，例如，通過(guò)動(dòng)態(tài)裝載。
• 為了避免創(chuàng)建一個(gè)與產(chǎn)品類(lèi)層次平行的工廠類(lèi)層次時(shí)。
• 當(dāng)一個(gè)類(lèi)的實(shí)例只能有幾個(gè)不同狀態(tài)組合中的一種時(shí)。建立相應(yīng)數(shù)目的原型并克隆它們可能比每次用合適的狀態(tài)手工實(shí)例化該類(lèi)更方便一些。

外觀模式：

• 客戶端不需要知道系統(tǒng)內(nèi)部的復(fù)雜聯(lián)系，整個(gè)系統(tǒng)只需提供一個(gè)"接待員"即可。
• 定義系統(tǒng)的入口。

3. 原型/外觀模式的優(yōu)缺點(diǎn)？
   原型模式：
   優(yōu)點(diǎn)：性能提高，逃避構(gòu)造函數(shù)的約束。
   缺點(diǎn)：

• 配備克隆方法需要對(duì)類(lèi)的功能進(jìn)行通盤(pán)考慮，這對(duì)于全新的類(lèi)不是很難，但對(duì)于已有的類(lèi)不一定很容易。
• 必須實(shí)現(xiàn) Cloneable 接口。
• 逃避構(gòu)造函數(shù)的約束。

外觀模式
優(yōu)點(diǎn)：減少系統(tǒng)相互依賴(lài)、提高靈活性、提高了安全性。
缺點(diǎn)：不符合開(kāi)閉原則，如果要改東西很麻煩，繼承重寫(xiě)都不合適。

4. 在實(shí)際項(xiàng)目中，原型模式很少單獨(dú)出現(xiàn)，一般是和工廠方法模式一起出現(xiàn)，通過(guò) clone 的方法創(chuàng)建一個(gè)對(duì)象，然后由工廠方法提供給調(diào)用者。（以后會(huì)在工廠模式代碼中體現(xiàn)）
   github原型模式示例源碼
   github外觀模式示例代碼
   外觀模式模型圖如下
   
   外觀模式.jpg

<5>裝飾模式

1. 何為裝飾模式？
   裝飾器模式（Decorator Pattern）允許向一個(gè)現(xiàn)有的對(duì)象添加新的功能，同時(shí)又不改變其結(jié)構(gòu)。這種類(lèi)型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它是作為現(xiàn)有的類(lèi)的一個(gè)包裝。
   這種模式創(chuàng)建了一個(gè)裝飾類(lèi)，用來(lái)包裝原有的類(lèi)，并在保持類(lèi)方法簽名完整性的前提下，提供了額外的功能。
2. 如何使用裝飾模式？
   在不想增加很多子類(lèi)的情況下擴(kuò)展類(lèi)。
3. 裝飾模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：裝飾類(lèi)和被裝飾類(lèi)可以獨(dú)立發(fā)展，不會(huì)相互耦合，裝飾模式是繼承的一個(gè)替代模式，裝飾模式可以動(dòng)態(tài)擴(kuò)展一個(gè)實(shí)現(xiàn)類(lèi)的功能。
   缺點(diǎn)：多層裝飾比較復(fù)雜。
4. github示例代碼iOS設(shè)計(jì)模式之裝飾模式
   模型圖如下

裝飾模式模型圖.png

<6>工廠模式

1. 何為工廠模式？

• 這種類(lèi)型的設(shè)計(jì)模式屬于創(chuàng)建型模式，它提供了一種創(chuàng)建對(duì)象的最佳方式。
• 在工廠模式中，我們?cè)趧?chuàng)建對(duì)象時(shí)不會(huì)對(duì)客戶端暴露創(chuàng)建邏輯，并且是通過(guò)使用一個(gè)共同的接口來(lái)指向新創(chuàng)建的對(duì)象。

2. 如何使用工廠模式？

• 我們明確地計(jì)劃不同條件下創(chuàng)建不同實(shí)例時(shí)。
• 作為一種創(chuàng)建類(lèi)模式，在任何需要生成復(fù)雜對(duì)象的地方，都可以使用工廠方法模式。有一點(diǎn)需要注意的地方就是復(fù)雜對(duì)象適合使用工廠模式，而簡(jiǎn)單對(duì)象，特別是只需要通過(guò) new 就可以完成創(chuàng)建的對(duì)象，無(wú)需使用工廠模式。如果使用工廠模式，就需要引入一個(gè)工廠類(lèi)，會(huì)增加系統(tǒng)的復(fù)雜度。

3. 工廠模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：

• 一個(gè)調(diào)用者想創(chuàng)建一個(gè)對(duì)象，只要知道其名稱(chēng)就可以了。
• 擴(kuò)展性高，如果想增加一個(gè)產(chǎn)品，只要擴(kuò)展一個(gè)工廠類(lèi)就可以。
• 屏蔽產(chǎn)品的具體實(shí)現(xiàn)，調(diào)用者只關(guān)心產(chǎn)品的接口。

缺點(diǎn)：

• 每次增加一個(gè)產(chǎn)品時(shí)，都需要增加一個(gè)具體類(lèi)和對(duì)象實(shí)現(xiàn)工廠，使得系統(tǒng)中類(lèi)的個(gè)數(shù)成倍增加，在一定程度上增加了系統(tǒng)的復(fù)雜度，同時(shí)也增加了系統(tǒng)具體類(lèi)的依賴(lài)。這并不是什么好事。

4. 抽象工廠模式

• 抽象工廠模式（Abstract Factory Pattern）是圍繞一個(gè)超級(jí)工廠創(chuàng)建其他工廠。該超級(jí)工廠又稱(chēng)為其他工廠的工廠。這種類(lèi)型的設(shè)計(jì)模式屬于創(chuàng)建型模式，它提供了一種創(chuàng)建對(duì)象的最佳方式。
• 在抽象工廠模式中，接口是負(fù)責(zé)創(chuàng)建一個(gè)相關(guān)對(duì)象的工廠，不需要顯式指定它們的類(lèi)。每個(gè)生成的工廠都能按照工廠模式提供對(duì)象。

5. githubiOS設(shè)計(jì)模式之抽象工廠模式

<7>橋接模式

1. 何為橋接模式？

• 橋接（Bridge）是用于把抽象化與實(shí)現(xiàn)化解耦，使得二者可以獨(dú)立變化。這種類(lèi)型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它通過(guò)提供抽象化和實(shí)現(xiàn)化之間的橋接結(jié)構(gòu)，來(lái)實(shí)現(xiàn)二者的解耦。
• 這種模式涉及到一個(gè)作為橋接的接口，使得實(shí)體類(lèi)的功能獨(dú)立于接口實(shí)現(xiàn)類(lèi)。這兩種類(lèi)型的類(lèi)可被結(jié)構(gòu)化改變而互不影響。

2. 如何使用橋接模式？

• 在有多種可能會(huì)變化的情況下，用繼承會(huì)造成類(lèi)爆炸問(wèn)題，擴(kuò)展起來(lái)不靈活。
• 實(shí)現(xiàn)系統(tǒng)可能有多個(gè)角度分類(lèi)，每一種角度都可能變化。
• 把這種多角度分類(lèi)分離出來(lái)，讓它們獨(dú)立變化，減少它們之間耦合。

3. 橋接模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn) ：抽象和實(shí)現(xiàn)的分離、優(yōu)秀的擴(kuò)展能力、實(shí)現(xiàn)細(xì)節(jié)對(duì)客戶透明。
   缺點(diǎn)：橋接模式的引入會(huì)增加系統(tǒng)的理解與設(shè)計(jì)難度，由于聚合關(guān)聯(lián)關(guān)系建立在抽象層，要求開(kāi)發(fā)者針對(duì)抽象進(jìn)行設(shè)計(jì)與編程。
4. githubiOS設(shè)計(jì)模式之橋接模式
   模型圖如下
   
   橋接模式原理.png

<8>代理模式

1. 何為代理模式？

• 在代理模式（Proxy Pattern）中，一個(gè)類(lèi)代表另一個(gè)類(lèi)的功能。這種類(lèi)型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式。
• 在代理模式中，我們創(chuàng)建具有現(xiàn)有對(duì)象的對(duì)象，以便向外界提供功能接口。

2. 如何使用代理模式？

• 在直接訪問(wèn)對(duì)象時(shí)帶來(lái)的問(wèn)題，比如說(shuō)：要訪問(wèn)的對(duì)象在遠(yuǎn)程的機(jī)器上。在面向?qū)ο笙到y(tǒng)中，有些對(duì)象由于某些原因（比如對(duì)象創(chuàng)建開(kāi)銷(xiāo)很大，或者某些操作需要安全控制，或者需要進(jìn)程外的訪問(wèn)），直接訪問(wèn)會(huì)給使用者或者系統(tǒng)結(jié)構(gòu)帶來(lái)很多麻煩，我們可以在訪問(wèn)此對(duì)象時(shí)加上一個(gè)對(duì)此對(duì)象的訪問(wèn)層。
• 想在訪問(wèn)一個(gè)類(lèi)時(shí)做一些控制。

3. 代理模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：

• 職責(zé)清晰、高擴(kuò)展性、智能化。

缺點(diǎn)：

• 由于在客戶端和真實(shí)主題之間增加了代理對(duì)象，因此有些類(lèi)型的代理模式可能會(huì)造成請(qǐng)求的處理速度變慢。
• 實(shí)現(xiàn)代理模式需要額外的工作，有些代理模式的實(shí)現(xiàn)非常復(fù)雜。

4. githubiOS設(shè)計(jì)模式之代理模式

<9>單例模式

1. 何為單例模式？
   這種模式涉及到一個(gè)單一的類(lèi)，該類(lèi)負(fù)責(zé)創(chuàng)建自己的對(duì)象，同時(shí)確保只有單個(gè)對(duì)象被創(chuàng)建。這個(gè)類(lèi)提供了一種訪問(wèn)其唯一的對(duì)象的方式，可以直接訪問(wèn)，不需要實(shí)例化該類(lèi)的對(duì)象。
   注意：

• 單例類(lèi)只能有一個(gè)實(shí)例。
• 單例類(lèi)必須自己創(chuàng)建自己的唯一實(shí)例。
• 單例類(lèi)必須給所有其他對(duì)象提供這一實(shí)例。

2. 如何使用單例模式？
   當(dāng)您想控制實(shí)例數(shù)目，節(jié)省系統(tǒng)資源的時(shí)候。
3. 單例模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：
   • 在內(nèi)存里只有一個(gè)實(shí)例，減少了內(nèi)存的開(kāi)銷(xiāo)，尤其是頻繁的創(chuàng)建和銷(xiāo)毀實(shí)例（比如管理學(xué)院首頁(yè)頁(yè)面緩存）。
   • 避免對(duì)資源的多重占用比如寫(xiě)文件操作。

缺點(diǎn)：

• 沒(méi)有接口，不能繼承，與單一職責(zé)原則沖突，一個(gè)類(lèi)應(yīng)該只關(guān)心內(nèi)部邏輯，而不關(guān)心外面怎么樣來(lái)實(shí)例化。

4. githubiOS設(shè)計(jì)模式之單例模式
   （注：代碼中的單例是“嚴(yán)格”的單例）
5. github單例模式優(yōu)化本地存儲(chǔ)

<10>備忘錄模式

1. 何為備忘錄模式？

備忘錄模式（Memento Pattern）保存一個(gè)對(duì)象的某個(gè)狀態(tài)，以便在適當(dāng)?shù)臅r(shí)候恢復(fù)對(duì)象。備忘錄模式屬于行為型模式。

2. 如何使用備忘錄模式？
   很多時(shí)候我們總是需要記錄一個(gè)對(duì)象的內(nèi)部狀態(tài)，這樣做的目的就是為了允許用戶取消不確定或者錯(cuò)誤的操作，能夠恢復(fù)到他原先的狀態(tài)，使得他有"后悔藥"可吃。
3. 備忘錄模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：

• 給用戶提供了一種可以恢復(fù)狀態(tài)的機(jī)制，可以使用戶能夠比較方便地回到某個(gè)歷史的狀態(tài)。
• 實(shí)現(xiàn)了信息的封裝，使得用戶不需要關(guān)心狀態(tài)的保存細(xì)節(jié)。

缺點(diǎn)：

• 消耗資源。如果類(lèi)的成員變量過(guò)多，勢(shì)必會(huì)占用比較大的資源，而且每一次保存都會(huì)消耗一定的內(nèi)存。

4. githubiOS設(shè)計(jì)模式之備忘錄模式

<11>生成器模式

1. 何為送生成器模式？
   建造者模式（Builder Pattern）使用多個(gè)簡(jiǎn)單的對(duì)象一步一步構(gòu)建成一個(gè)復(fù)雜的對(duì)象。這種類(lèi)型的設(shè)計(jì)模式屬于創(chuàng)建型模式，它提供了一種創(chuàng)建對(duì)象的最佳方式。
2. 如何使用生成器模式？

• 主要解決在軟件系統(tǒng)中，有時(shí)候面臨著"一個(gè)復(fù)雜對(duì)象"的創(chuàng)建工作，其通常由各個(gè)部分的子對(duì)象用一定的算法構(gòu)成；由于需求的變化，這個(gè)復(fù)雜對(duì)象的各個(gè)部分經(jīng)常面臨著劇烈的變化，但是將它們組合在一起的算法卻相對(duì)穩(wěn)定。
• 一些基本部件不會(huì)變，而其組合經(jīng)常變化的時(shí)候。

3. 生成器模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：

• 建造者獨(dú)立，易擴(kuò)展。
• 便于控制細(xì)節(jié)風(fēng)險(xiǎn)。

缺點(diǎn)：

• 產(chǎn)品必須有共同點(diǎn)，范圍有限制。
• 如內(nèi)部變化復(fù)雜，會(huì)有很多的建造類(lèi)。

4. 使用場(chǎng)景

• 需要生成的對(duì)象具有復(fù)雜的內(nèi)部結(jié)構(gòu)。
• 需要生成的對(duì)象內(nèi)部屬性本身相互依賴(lài)。
  注意事項(xiàng)：與工廠模式的區(qū)別是：建造者模式更加關(guān)注與零件裝配的順序。

5. githubiOS設(shè)計(jì)模式之制造者模式(參考制造汽車(chē)的過(guò)程)

6. 制造者模式思維導(dǎo)圖

   
   
   制造者模式.png

<12>命令模式

1. 何為命令模式？
   命令模式（Command Pattern）是一種數(shù)據(jù)驅(qū)動(dòng)的設(shè)計(jì)模式，它屬于行為型模式。請(qǐng)求以命令的形式包裹在對(duì)象中，并傳給調(diào)用對(duì)象。調(diào)用對(duì)象尋找可以處理該命令的合適的對(duì)象，并把該命令傳給相應(yīng)的對(duì)象，該對(duì)象執(zhí)行命令。
2. 主要解決的問(wèn)題？
   在軟件系統(tǒng)中，行為請(qǐng)求者與行為實(shí)現(xiàn)者通常是一種緊耦合的關(guān)系，但某些場(chǎng)合，比如需要對(duì)行為進(jìn)行記錄、撤銷(xiāo)或重做、事務(wù)等處理時(shí)，這種無(wú)法抵御變化的緊耦合的設(shè)計(jì)就不太合適。
3. 如何使用命令模式？
   在某些場(chǎng)合，比如要對(duì)行為進(jìn)行"記錄、撤銷(xiāo)/重做、事務(wù)"等處理，這種無(wú)法抵御變化的緊耦合是不合適的。在這種情況下，如何將"行為請(qǐng)求者"與"行為實(shí)現(xiàn)者"解耦？將一組行為抽象為對(duì)象，可以實(shí)現(xiàn)二者之間的松耦合。
4. 關(guān)鍵代碼？
   定義三個(gè)角色：

• received 真正的命令執(zhí)行對(duì)象
• Command
• invoker 使用命令對(duì)象的入口

5. 命令模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)：降低了系統(tǒng)耦合度，新的命令可以很容易添加到系統(tǒng)中去。
   缺點(diǎn)：使用命令模式可能會(huì)導(dǎo)致某些系統(tǒng)有過(guò)多的具體命令類(lèi)。
6. 使用場(chǎng)景
   認(rèn)為是命令的地方都可以使用命令模式
7. githubiOS設(shè)計(jì)模式之命令模式（實(shí)現(xiàn)View的明亮變化）

<13>組合模式

1. 何為組合模式？
   組合模式（Composite Pattern），又叫部分整體模式，是用于把一組相似的對(duì)象當(dāng)作一個(gè)單一的對(duì)象。組合模式依據(jù)樹(shù)形結(jié)構(gòu)來(lái)組合對(duì)象，用來(lái)表示部分以及整體層次。這種類(lèi)型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它創(chuàng)建了對(duì)象組的樹(shù)形結(jié)構(gòu)。
   這種模式創(chuàng)建了一個(gè)包含自己對(duì)象組的類(lèi)。該類(lèi)提供了修改相同對(duì)象組的方式。
2. 主要解決的問(wèn)題？
   它在我們樹(shù)型結(jié)構(gòu)的問(wèn)題中，模糊了簡(jiǎn)單元素和復(fù)雜元素的概念，客戶程序可以向處理簡(jiǎn)單元素一樣來(lái)處理復(fù)雜元素，從而使得客戶程序與復(fù)雜元素的內(nèi)部結(jié)構(gòu)解耦。
3. 如何使用適配器模式？
   樹(shù)枝和葉子實(shí)現(xiàn)統(tǒng)一接口，樹(shù)枝內(nèi)部組合該接口。
4. 關(guān)鍵代碼?
   樹(shù)枝內(nèi)部組合該接口，并且含有內(nèi)部屬性 List，里面放 Component。
5. 適配器模式的優(yōu)缺點(diǎn)？
   優(yōu)點(diǎn)： 高層模塊調(diào)用簡(jiǎn)單、節(jié)點(diǎn)自由增加。
   缺點(diǎn)：在使用組合模式時(shí)，其葉子和樹(shù)枝的聲明都是實(shí)現(xiàn)類(lèi)，而不是接口，違反了依賴(lài)倒置原則。
6. 使用場(chǎng)景？
   部分、整體場(chǎng)景，如樹(shù)形菜單，文件、文件夾的管理。
   （注：定義時(shí)為具體類(lèi)。）
7. githubiOS設(shè)計(jì)模式之組合模式（模擬文件夾）

總結(jié)

1. 代碼建議有興趣的同學(xué)可以自己敲一遍，便于加深理解。如果覺(jué)得github代碼還不錯(cuò)請(qǐng)不要吝惜star，每一個(gè)star都是我堅(jiān)持走下去的動(dòng)力，三克油。
2. 每種設(shè)計(jì)模式都是有特定的使用背景的，在設(shè)計(jì)之前要多加進(jìn)入‘上帝模式’，站的更高才能看的更遠(yuǎn)。
3. 本文的13中設(shè)計(jì)模式只是比較常用的一些設(shè)計(jì)模式，還有其他的一些設(shè)計(jì)模式，希望不喜勿噴。
4. 如果有什么建議請(qǐng)多多留言，我會(huì)一一回復(fù)的。
5. 如果對(duì)設(shè)計(jì)模式還有濃厚的興趣，可以看看《iOS21種設(shè)計(jì)模式》。

設(shè)計(jì)模式的基本原則，不夠清楚的話，可以看這里

寫(xiě)作記錄

（2017.2.13iOS設(shè)計(jì)模式之適配器模式）
（2017.2.15iOS設(shè)計(jì)模式之觀察者模式）
（2017.2.16iOS設(shè)計(jì)模式之策略模式）
（2017.2.23iOS設(shè)計(jì)模式之單例模式）
（2017.2.24單例模式優(yōu)化本地存儲(chǔ)）
（2017.2.26iOS設(shè)計(jì)模式之原型/外觀模式）
（2017.2.28iOS設(shè)計(jì)模式之裝飾模式）
（2017.3.1iOS設(shè)計(jì)模式之工廠模式）
（2017.3.2iOS設(shè)計(jì)模式之橋接模式）
（2017.3.3iOS設(shè)計(jì)模式之代理模式）
（2017.3.4iOS設(shè)計(jì)模式之制造者模式）
（2017.3.5iOS設(shè)計(jì)模式之命令模式）
（2017.3.6iOS設(shè)計(jì)模式之組合模式）

錯(cuò)誤糾正

1.外觀模式github鏈接錯(cuò)誤,2018.8.24已更正.
2.備忘錄模式,代碼NSObject+MementoCenter,相關(guān)文件沒(méi)有添加到項(xiàng)目中,現(xiàn)2018.8.24更正.