#1.模板模式
一.模式定義
在模板模式（Template Pattern）中货岭，一個(gè)抽象類公開定義了執(zhí)行它的方法的方式/模板。它的子類可以按需要重寫方法實(shí)現(xiàn)徘禁，但調(diào)用將以抽象類中定義的方式進(jìn)行诅诱。這種類型的設(shè)計(jì)模式屬于行為型模式。
二.UML圖
模板模式UML圖
分析：在我們的項(xiàng)目中API的封裝就是一個(gè)例子送朱。所有具體的API請(qǐng)求類都繼承于NXSuperRESTAPIRequest這個(gè)抽象類娘荡，并實(shí)現(xiàn)其協(xié)議方法
-(NSURLRequest *) generateRequestObject:(id) object;
- (Analysis)analysisReturnData;
雖然每個(gè)API的具體request和result不同，但是它們都遵循發(fā)請(qǐng)求驶沼，解析結(jié)果兩個(gè)大步驟炮沐，，每個(gè)具體API在各自子類中進(jìn)行不同的實(shí)現(xiàn)回怜。
三.應(yīng)用環(huán)境
1 .封裝不變部分大年，擴(kuò)展可變部分、提取公共代碼玉雾，便于維護(hù)鲜戒。
2. 行為由父類控制，子類實(shí)現(xiàn)抹凳。
3.實(shí)現(xiàn)某一個(gè)功能或事件有一套統(tǒng)一的步驟或規(guī)范遏餐。
四.模板模式的優(yōu)缺點(diǎn)
1.優(yōu)點(diǎn)
* 模板方法模式通過(guò)把不變的行為搬移到超類，去除了子類中的重復(fù)代碼赢底。
* 子類實(shí)現(xiàn)算法的某些細(xì)節(jié)失都，有助于算法的擴(kuò)展。
* 通過(guò)一個(gè)父類調(diào)用子類實(shí)現(xiàn)的操作幸冻，通過(guò)子類擴(kuò)展增加新的行為粹庞，符合“開放-封閉原則”。
2.缺點(diǎn)
*每個(gè)不同的實(shí)現(xiàn)都需要定義一個(gè)子類洽损，這會(huì)導(dǎo)致類的個(gè)數(shù)的增加庞溜，系統(tǒng)更加龐大。
=====================================================================
#2.策略模式
一.模式定義
策略模式是指對(duì)一系列的算法定義碑定，并將每一個(gè)算法封裝起來(lái)流码，而且使它們還可以相互替換。策略模式讓算法獨(dú)立于使用它的客戶而獨(dú)立變化延刘。
場(chǎng)景：不同方式的排序
例子漫试，UIButton的創(chuàng)建可以選擇不同的type。
二.UML圖
策略模式UML圖
分析：
—抽象策略角色（Strategy）： 策略類碘赖，通常由一個(gè)接口或者抽象類實(shí)現(xiàn)驾荣。
—具體策略角色(ConcreteStrategyA/B/C)：包裝了相關(guān)的算法和行為外构。
—環(huán)境角色(Context)：持有一個(gè)策略類的引用，最終給客戶端調(diào)用播掷。
三.應(yīng)用環(huán)境
1审编、 需要在不同情況下使用不同的策略(算法)，或者策略還可能在未來(lái)用其它方式來(lái)實(shí)現(xiàn)歧匈。
2割笙、 對(duì)客戶隱藏具體策略(算法)的實(shí)現(xiàn)細(xì)節(jié)，彼此完全獨(dú)立眯亦。
四.優(yōu)缺點(diǎn)
1.優(yōu)點(diǎn)
*算法可以自由切換伤溉。
*避免使用多重條件判斷。
*擴(kuò)展性良好妻率。
2.缺點(diǎn)
*策略類增多乱顾，系統(tǒng)更加龐大。
五.demo
OC代碼鏈接：https://github.com/yinhu0709/StrategyPattern.git
=====================================================================
#3.命令模式
一.模式定義
命令模式（Command Pattern）是一種數(shù)據(jù)驅(qū)動(dòng)的設(shè)計(jì)模式宫静，它屬于行為型模式走净。請(qǐng)求以命令的形式包裹在對(duì)象中，并傳給調(diào)用對(duì)象孤里。調(diào)用對(duì)象尋找可以處理該命令的合適的對(duì)象伏伯，并把該命令傳給相應(yīng)的對(duì)象，該對(duì)象執(zhí)行命令捌袜。
場(chǎng)景：
電視機(jī)遙控器 :
電視機(jī)是請(qǐng)求的接收者说搅，
遙控器是請(qǐng)求的發(fā)送者，
遙控器上有一些按鈕虏等，不同的按鈕對(duì)應(yīng)電視機(jī)的不同操作弄唧。
二.UML圖
分析：抽象命令類(Command):聲明執(zhí)行操作的接口。調(diào)用接收者相應(yīng)的操作霍衫，以實(shí)現(xiàn)執(zhí)行的方法Execute候引。
具體命令類(ConcreteCommand):創(chuàng)建一個(gè)具體命令對(duì)象并設(shè)定它的接收者。通常會(huì)持有接收者敦跌，并調(diào)用接收者的功能來(lái)完成命令要執(zhí)行的操作澄干。
調(diào)用者(Invoker):要求該命令執(zhí)行這個(gè)請(qǐng)求。通常會(huì)持有命令對(duì)象柠傍，可以持有很多的命令對(duì)象麸俘。
接收者(Receiver):知道如何實(shí)施與執(zhí)行一個(gè)請(qǐng)求相關(guān)的操作。
客戶類(Client):創(chuàng)建具體的命令對(duì)象携兵，并且設(shè)置命令對(duì)象的接收者疾掰。真正使用命令的客戶端是從Invoker來(lái)觸發(fā)執(zhí)行。
三.應(yīng)用環(huán)境
1.系統(tǒng)需要將請(qǐng)求調(diào)用者和請(qǐng)求接收者解耦徐紧，使得調(diào)用者和接收者不直接交互静檬。
2.系統(tǒng)需要支持命令的撤銷(Undo)操作和恢復(fù)(Redo)操作。
3.需要實(shí)現(xiàn)命令組合的需求并级。
四.命令模式的優(yōu)缺點(diǎn)
1.優(yōu)點(diǎn)
*降低系統(tǒng)的耦合度:調(diào)用操作的對(duì)象與知道如何實(shí)現(xiàn)該操作的對(duì)象解耦拂檩。
*新的命令易擴(kuò)展。
2.缺點(diǎn)
*命令類增多嘲碧，系統(tǒng)更加龐大稻励。
五.demo
OC代碼鏈接：https://github.com/yinhu0709/CommandPattern.git
====================================================================
參考鏈接：http://www.runoob.com/design-pattern/strategy-pattern.html
參考鏈接：http://blog.csdn.net/hguisu/article/details/7549895
