一直想寫一系列關(guān)于設(shè)計(jì)模式的文章，一直覺(jué)得自己理解不夠，遲遲不能動(dòng)筆。當(dāng)然，現(xiàn)在動(dòng)筆也不代表著理解透徹了，只是希望記錄下一些看書的重點(diǎn)和自己的理解，以便重復(fù)翻閱，也希望能和其他開發(fā)者探討交流。
本系列文章是根據(jù)《Objective-C 編程之道》總結(jié)的，想仔細(xì)研讀的可以去看該文章。這本書寫得不錯(cuò)，就是年代比較久遠(yuǎn)，用的還是MRC，一些寫法還是比較舊的，不過(guò)關(guān)于設(shè)計(jì)模式這塊，還是講得淺顯易懂的。

一. 什么是設(shè)計(jì)模式？

設(shè)計(jì)模式是為特定場(chǎng)景下的問(wèn)題而定制的解決方案。設(shè)計(jì)模式是對(duì)特定面向?qū)ο笤O(shè)計(jì)問(wèn)題主要方面的一種抽象，體現(xiàn)了面向?qū)ο笤O(shè)計(jì)的重要思想。在程序設(shè)計(jì)中使用了設(shè)計(jì)模式，將來(lái)就更易于復(fù)用與擴(kuò)展，更易于變更。

有人常把架構(gòu)模式和設(shè)計(jì)模式混在一起，比如MVC就屬于架構(gòu)模式。在MVC中，對(duì)象在應(yīng)用程序中被分成三組，分別扮演模型、視圖和控制器，它決定了對(duì)象或類的職責(zé)（應(yīng)該屬于MVC這三組中的哪一組），它包含了若干基礎(chǔ)的設(shè)計(jì)模式，比如cocoa的MVC用到的模式有：組合（視圖層次體系）、命令（target-action機(jī)制）、中介者（控制器）、策略（控制器）、觀察者（通知）。

二. 影響設(shè)計(jì)的問(wèn)題

影響設(shè)計(jì)模式有六大原則，這些原則是構(gòu)建可復(fù)用、可維護(hù)的面向?qū)ο髴?yīng)用程序的經(jīng)驗(yàn)法則。這邊我不打算細(xì)說(shuō)，很多原則（或者說(shuō)思想）我們一直在默默遵守，比如職責(zé)單一原則、開閉原則，想具體了解可以看下這篇文章設(shè)計(jì)模式六大原則。

這邊我主要討論兩個(gè)問(wèn)題（或者說(shuō)原則）:

• ① 針對(duì)接口編程而不是針對(duì)實(shí)現(xiàn)編程
• ② 優(yōu)先使用對(duì)象組合而不是類繼承

① 針對(duì)接口編程而不是針對(duì)實(shí)現(xiàn)編程

在OC中針對(duì)接口編程有兩種方式：
1）抽象基類。。抽象基類可以生成其他子類可以共享的默認(rèn)行為，抽象基類與通常的類相似，只是預(yù)留了一些可以或應(yīng)該由子類重載的行為。
2）協(xié)議。協(xié)議只是定義抽象行為的“接口”，實(shí)現(xiàn)協(xié)議的類定義這些方法的實(shí)現(xiàn)。

實(shí)現(xiàn)協(xié)議或者從抽象類繼承，使得對(duì)象共享相同的接口。子類型的所有對(duì)象都可以針對(duì)協(xié)議或抽象類的接口的請(qǐng)求做出應(yīng)答。這樣做有以下兩點(diǎn)好處：
1）只要對(duì)象符合客戶端所要求的接口，客戶端就不必在意所使用對(duì)象的確切類型。
2）客戶端只知道定義接口的協(xié)議或者抽象類，因此客戶端對(duì)對(duì)象的類一無(wú)所知。

通過(guò)給程序的變動(dòng)部分定義接口而對(duì)其封裝和隔離，這些部分的變動(dòng)就獨(dú)立于程序的其他部分，因?yàn)樗鼈儾灰蕾囉谌魏渭?xì)節(jié)。以后就可以變更或拓展這些可變的部分而不影響程序的其他部分。程序?qū)⒁虼四軌蚋`活而可靠地進(jìn)行變更，因?yàn)槲覀兿瞬糠峙c部分之間的依賴關(guān)系并減少了耦合。
所以說(shuō)，在考慮設(shè)計(jì)模式的時(shí)候，一定要將設(shè)計(jì)模式的變化點(diǎn)搞清楚，而不僅僅是考慮設(shè)計(jì)模式的場(chǎng)景、實(shí)現(xiàn)方式以及類和對(duì)象之間的耦合關(guān)系，這樣才不會(huì)導(dǎo)致設(shè)計(jì)模式的濫用，以至于該變化的沒(méi)變化，不該變化的經(jīng)常變化。

當(dāng)然，具體選擇協(xié)議或者抽象基類應(yīng)該根據(jù)實(shí)際場(chǎng)景去衡量。在多繼承的方案中（OC不支持多繼承），我們可以為不需要子類化其他類的類定義一個(gè)抽象基類，然后可以定義一個(gè)同名協(xié)議，讓包括這個(gè)抽象基類在內(nèi)的其他類去實(shí)現(xiàn)。（例：NSObject基類又遵守NSObject協(xié)議）。

② 優(yōu)先使用對(duì)象組合而不是類繼承

在拓展功能的時(shí)候，我們有兩種方案：對(duì)象組合和類繼承。
類繼承（子類化）讓我們可以使用其他類來(lái)定義類的實(shí)現(xiàn)。子類化常被稱為白箱復(fù)用，因?yàn)楦割惖膬?nèi)部描述與細(xì)節(jié)通常對(duì)子類可見(jiàn)。
對(duì)象組合可以替代類繼承。對(duì)象組合要求被組合的對(duì)象具有定義良好的接口，并且通過(guò)從其他對(duì)象得到的引用在運(yùn)行時(shí)動(dòng)態(tài)定義。所以可以將對(duì)象組合到其他對(duì)象上，以構(gòu)建更加復(fù)雜的功能。由于對(duì)象的內(nèi)部細(xì)節(jié)對(duì)其他對(duì)象不可見(jiàn)，這種類型的復(fù)用被稱為黑箱復(fù)用。

使用類繼承和對(duì)象組合的復(fù)用各有優(yōu)缺點(diǎn)：
類繼承
優(yōu)點(diǎn)：類繼承簡(jiǎn)單直接，因?yàn)殛P(guān)系在編譯時(shí)靜態(tài)定義，被復(fù)用的實(shí)現(xiàn)也易于修改。
缺點(diǎn)：和子類的耦合度太高，父類實(shí)現(xiàn)的任何變更都會(huì)強(qiáng)制子類進(jìn)行變更。子類直接面對(duì)父類實(shí)現(xiàn)的細(xì)節(jié)，因此破壞了封裝性。

對(duì)象組合
優(yōu)點(diǎn)：不會(huì)破壞封裝性，因?yàn)橹煌ㄟ^(guò)接口來(lái)訪問(wèn)對(duì)象。大大減少實(shí)現(xiàn)的依存關(guān)系，因?yàn)閷?duì)象的實(shí)現(xiàn)是通過(guò)接口來(lái)定義的。有助于保持類的封裝以專注單一任務(wù)，類及其層次結(jié)構(gòu)能夠保持整潔，不至于過(guò)度膨脹。
缺點(diǎn)：設(shè)計(jì)涉及對(duì)象較多，系統(tǒng)的行為與不同對(duì)象的關(guān)系，而不是定義在單個(gè)類中。

所以說(shuō)，類繼承不能被濫用，針對(duì)類繼承的討論可以看下casa的這系列文章 跳出面向?qū)ο笏枷?一) 繼承。
優(yōu)先使用對(duì)象組合而不是類繼承并不是說(shuō)不能使用類繼承，需要根據(jù)具體情況對(duì)如何復(fù)用類和對(duì)象作出清晰的判斷。如果系統(tǒng)設(shè)計(jì)得合理，類繼承與對(duì)象組合可以相互配合。設(shè)計(jì)類時(shí)，優(yōu)先考慮對(duì)象組合，然后尋找出冗余行為，進(jìn)行設(shè)計(jì)細(xì)化（如果找到冗余行為意味著此處應(yīng)該使用類繼承）。

二. 設(shè)計(jì)模式的介紹

在《Objective-C 編程之道》中，將設(shè)計(jì)模式分成了八種類型。我們需要根據(jù)特定的場(chǎng)景和需求來(lái)選擇設(shè)計(jì)模式。比如，當(dāng)需要?jiǎng)?chuàng)建對(duì)象時(shí)，不是隨意New一個(gè)，而是考慮下耦合性，可擴(kuò)展性，使用場(chǎng)景等等，來(lái)選擇合適的設(shè)計(jì)模式。

iOS設(shè)計(jì)模式.png