架構(gòu)沒(méi)有好壞之分，合適的架構(gòu)就是好的架構(gòu)。在選擇一個(gè)合適的架構(gòu)方式前，要清楚需要做的事情、解決什么問(wèn)題、業(yè)務(wù)方面需要得到什么，脫離業(yè)務(wù)談架構(gòu)就是純粹的耍流氓。

架構(gòu)原則：易讀性、易維護(hù)性、易擴(kuò)展性。

本章會(huì)先介紹架構(gòu)模式，在此基礎(chǔ)上討論組件化；然后討論下混合開(kāi)發(fā)；最后梳理下設(shè)計(jì)模式。

架構(gòu)模式

架構(gòu)模式的出現(xiàn)時(shí)為了管理復(fù)雜的應(yīng)用程序，這樣可以在一個(gè)時(shí)間內(nèi)專門(mén)關(guān)注一個(gè)方面。例如，您可以在不依賴業(yè)務(wù)邏輯的情況下專注于視圖設(shè)計(jì)。同時(shí)也讓?xiě)?yīng)用程序的測(cè)試更加容易。同時(shí)也簡(jiǎn)化了分組開(kāi)發(fā)。不同的開(kāi)發(fā)人員可同時(shí)開(kāi)發(fā)視圖、控制器邏輯和業(yè)務(wù)邏輯。我們經(jīng)常說(shuō)的MVC架構(gòu)、MVVM架構(gòu)屬于此類。

MVC

傳統(tǒng)移動(dòng)APP開(kāi)發(fā)的MVC架構(gòu)：

1、短平快，實(shí)用于快速上線搶占市場(chǎng)
2、這種架構(gòu)以層次結(jié)構(gòu)簡(jiǎn)單清晰，代碼容易開(kāi)發(fā)而被大多數(shù)人所接受。

在MVC的體系架構(gòu)中，Controller層負(fù)責(zé)整個(gè)APP中主要邏輯功能的實(shí)現(xiàn)；Model層則負(fù)責(zé)數(shù)據(jù)結(jié)構(gòu)的描述以及數(shù)據(jù)持久化的功能；而View層作為展現(xiàn)層負(fù)責(zé)渲染整個(gè)APP的UI。分工清晰，簡(jiǎn)潔明了；并且這種系統(tǒng)架構(gòu)在語(yǔ)言框架層就得到了Apple的支持，所以非常適用于APP的startup開(kāi)發(fā)。然后，這種架構(gòu)在開(kāi)發(fā)的后期會(huì)由于其超高耦和性，從而造就龐大Controller層，而這也是一直被人所詬病。最終的MVC都從Model-View-Controller走向了Massive-View-Controller 的終點(diǎn)。

當(dāng)業(yè)務(wù)發(fā)展到一定層次，單一主營(yíng)業(yè)務(wù)或單一App發(fā)展為百花齊放百家爭(zhēng)鳴的多元業(yè)務(wù)格局，MVC的弊端就開(kāi)始無(wú)限放大，臃腫的Controller層會(huì)呈現(xiàn)出幾千行代碼，對(duì)于喜歡一個(gè)函數(shù)只做一件事的我而言，是完全無(wú)法接受的，也許有的人會(huì)選擇采用類別切分成多個(gè)Controller來(lái)假性“解決”。這時(shí)候，降低耦合，復(fù)用已有模塊成了架構(gòu)的第一要?jiǎng)?wù)。
無(wú)論哪種架構(gòu)，都能以MVC為基準(zhǔn)，不斷調(diào)整重構(gòu)、不斷劃分職責(zé)、不斷細(xì)化得來(lái)的。所以，能夠掌握如何劃分職責(zé)，將視圖、邏輯、數(shù)據(jù)三者連接起來(lái)，易用并方便維護(hù)，那么就可以了，無(wú)所謂什么模式。

MVP

作為MVC的進(jìn)階版, 提出區(qū)分業(yè)務(wù)邏輯和業(yè)務(wù)展示, 將所有的業(yè)務(wù)邏輯轉(zhuǎn)移到P層, V層接受P層的數(shù)據(jù)更新通知進(jìn)行頁(yè)面展示. 優(yōu)點(diǎn)在于良好的分層帶來(lái)了友好的單元測(cè)試, 缺點(diǎn)在于分層會(huì)讓代碼邏輯優(yōu)點(diǎn)繞, 同時(shí)也帶來(lái)了大量的代碼工作, 對(duì)程序員不夠友好.

MVVM

數(shù)據(jù)綁定做數(shù)據(jù)更新, 減少了大量的代碼工作, 同時(shí)優(yōu)化了代碼邏輯, 只是學(xué)習(xí)成本有點(diǎn)高, 對(duì)新手不夠友好.

依照需求搭建你的iOS架構(gòu)

對(duì)于絕大多數(shù)iOS開(kāi)發(fā)者而言，日常的工作就是重復(fù)“網(wǎng)絡(luò)請(qǐng)求-》數(shù)據(jù)存儲(chǔ)-》頁(yè)面展示和交互”。再多一點(diǎn)就是埋點(diǎn)收集用戶數(shù)據(jù)，提供給產(chǎn)品或運(yùn)營(yíng)；自動(dòng)化打包或自動(dòng)化測(cè)試...

如何進(jìn)行架構(gòu)設(shè)計(jì)？

• 搞清楚要解決那些問(wèn)題，找到問(wèn)題的充要條件
• 問(wèn)題分類，分模塊
• 推演未來(lái)可能的走向，以備未來(lái)之需
• 解決依賴關(guān)系中最基礎(chǔ)的問(wèn)題，實(shí)現(xiàn)基礎(chǔ)模塊，然后再用基礎(chǔ)模塊堆疊出整個(gè)架構(gòu)
• 打點(diǎn)，跑單元測(cè)試，跑性能測(cè)試，對(duì)應(yīng)優(yōu)化

架構(gòu)分層

常見(jiàn)的分層架構(gòu)，有三層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層。也有四層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層、網(wǎng)絡(luò)層、本地?cái)?shù)據(jù)層。

舉個(gè)例子：你要設(shè)計(jì)一個(gè)即時(shí)通訊的服務(wù)端架構(gòu)，怎么分層？
記住，不要一上來(lái)就把三層架構(gòu)的規(guī)范套上去，這樣做是做不出好架構(gòu)的。你要先確定都需要解決哪些問(wèn)題。這里只是舉例子，我隨意列出一點(diǎn)意思意思就好了：
要解決用戶登錄、退出的問(wèn)題
解決不同用戶間數(shù)據(jù)交流的問(wèn)題
解決用戶數(shù)據(jù)存儲(chǔ)的問(wèn)題
如果是多臺(tái)服務(wù)器的集群，就要解決用戶連接的尋址問(wèn)題

解決第一個(gè)問(wèn)題需要一個(gè)鏈接管理模塊，鏈接管理模塊一般是通過(guò)鏈接池來(lái)實(shí)現(xiàn)。 解決第二個(gè)問(wèn)題需要有一個(gè)數(shù)據(jù)交換模塊，從A接收來(lái)的數(shù)據(jù)要給到B，這個(gè)事情由這個(gè)模塊來(lái)做。 解決第三個(gè)問(wèn)題需要有個(gè)數(shù)據(jù)庫(kù)，如果是服務(wù)于大量用戶，那么就需要一個(gè)緩沖區(qū)，只有當(dāng)需要存儲(chǔ)的數(shù)據(jù)達(dá)到一定量時(shí)才執(zhí)行寫(xiě)操作。 解決第四個(gè)問(wèn)題可以有幾種解決方案，一個(gè)是集群中有那么幾臺(tái)服務(wù)器作為尋路服務(wù)器，所有尋路的服務(wù)交給那幾臺(tái)去做，那么你需要開(kāi)發(fā)一個(gè)尋路服務(wù)的Daemon?；蛘哂脧V播方式尋路，但如果尋路頻次非常高，會(huì)造成集群內(nèi)部網(wǎng)絡(luò)負(fù)載特別大。這是你要權(quán)衡的地方，目前流行的思路是去中心化，那么要解決網(wǎng)絡(luò)負(fù)載的問(wèn)題，你就可以考慮配置一個(gè)緩存。
于是我們有了這些模塊：
鏈接管理、數(shù)據(jù)交換、數(shù)據(jù)庫(kù)及其配套模塊、尋路模塊
做到這里還遠(yuǎn)遠(yuǎn)沒(méi)有結(jié)束，你要繼續(xù)針對(duì)這四個(gè)模塊繼續(xù)往下細(xì)分，直到足夠小為止。但是這里只是舉例子，所以就不往下深究了。

業(yè)務(wù)展示

業(yè)務(wù)層和展示層主要是要注意業(yè)務(wù)耦合度和基礎(chǔ)模塊的封裝。在此基礎(chǔ)上采用組件化。

網(wǎng)絡(luò)請(qǐng)求

網(wǎng)絡(luò)層在一個(gè)App中也是一個(gè)不可缺少的部分，工程師們?cè)诰W(wǎng)絡(luò)層能夠發(fā)揮的空間也比較大。另外，蘋(píng)果對(duì)網(wǎng)絡(luò)請(qǐng)求部分已經(jīng)做了很好的封裝，業(yè)界的AFNetworking也被廣泛使用。加入說(shuō)需要你自己搭建一個(gè)HTTP框架，你需要考慮哪些模塊呢？
1、網(wǎng)絡(luò)層的安全機(jī)制；
思路：設(shè)計(jì)簽名，即在請(qǐng)求中攜帶同服務(wù)器商量好的密鑰hash出來(lái)的字符串。同時(shí)采用安全的HTTPS機(jī)制；
2、網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接API的設(shè)計(jì)
思路：以什么方式傳送數(shù)據(jù)（delegate、notification、block、KVO、target-Action）、傳送什么樣的數(shù)據(jù)給業(yè)務(wù)層（一般APP從服務(wù)器得到的數(shù)據(jù)是Json格式，很多APP直接轉(zhuǎn)化成對(duì)象）
3、網(wǎng)絡(luò)層的優(yōu)化方案
思路：連接復(fù)用、緩存

數(shù)據(jù)存儲(chǔ)

持久化方案不管是服務(wù)端還是客戶端，都是一個(gè)非常值得討論的話題。尤其是在服務(wù)端，持久化方案的優(yōu)劣往往都會(huì)在一定程度上影響到產(chǎn)品的性能。然而在客戶端，只有為數(shù)不多的業(yè)務(wù)需求會(huì)涉及持久化方案，而且在大多數(shù)情況下，持久化方案對(duì)性能的要求并不是特別苛刻。所以我在移動(dòng)端這邊做持久化方案設(shè)計(jì)的時(shí)候，考慮更多的是方案的可維護(hù)和可拓展，然后在此基礎(chǔ)上才是性能調(diào)優(yōu)。

• 根據(jù)需求決定持久化方案
• 持久層與業(yè)務(wù)層之間的隔離
• 持久層與業(yè)務(wù)層的交互方式
• 數(shù)據(jù)遷移方案
• 數(shù)據(jù)同步方案

思路：可維護(hù)性、可擴(kuò)展性、性能消耗

在有需要持久化需求的時(shí)候，我們有非常多的方案可供選擇：NSUserDefault、KeyChain、File，以及基于數(shù)據(jù)庫(kù)的無(wú)數(shù)子方案。因此，當(dāng)有需要持久化的需求的時(shí)候，我們首先考慮的是應(yīng)該采用什么手段去進(jìn)行持久化。

• NSUserDefault
  一般來(lái)說(shuō)，小規(guī)模數(shù)據(jù)，弱業(yè)務(wù)相關(guān)數(shù)據(jù)，都可以放到NSUserDefault里面，內(nèi)容比較多的數(shù)據(jù)，強(qiáng)業(yè)務(wù)相關(guān)的數(shù)據(jù)就不太適合NSUserDefault了。我就見(jiàn)到過(guò)有些業(yè)務(wù)線會(huì)把大部分業(yè)務(wù)數(shù)據(jù)都塞到NSUserDefault里面去，當(dāng)時(shí)看代碼的時(shí)候我特么就直接跪了。。。問(wèn)起來(lái)為什么這么做？結(jié)果說(shuō)因?yàn)閷?xiě)起來(lái)方便～你妹。。。

• keychain
  Keychain是蘋(píng)果提供的帶有可逆加密的存儲(chǔ)機(jī)制，普遍用在各種存密碼的需求上。另外，由于App卸載只要系統(tǒng)不重裝，Keychain中的數(shù)據(jù)依舊能夠得到保留，以及可被iCloud同步的特性，大家都會(huì)在這里存儲(chǔ)用戶唯一標(biāo)識(shí)串。所以有需要加密、需要存iCloud的敏感小數(shù)據(jù)，一般都會(huì)放在Keychain。

• 文件存儲(chǔ)
  文件存儲(chǔ)包括了Plist、archive、Stream等方式，一般結(jié)構(gòu)化的數(shù)據(jù)或者需要方便查詢的數(shù)據(jù)，都會(huì)以Plist的方式去持久化。Archive方式適合存儲(chǔ)平時(shí)不太經(jīng)常使用但很大量的數(shù)據(jù)，或者讀取之后希望直接對(duì)象化的數(shù)據(jù)，因?yàn)锳rchive會(huì)將對(duì)象及其對(duì)象關(guān)系序列化，以至于讀取數(shù)據(jù)的時(shí)候需要Decode很花時(shí)間，Decode的過(guò)程可以是解壓，也可以是對(duì)象化，這個(gè)可以根據(jù)具體<NSCoding>中的實(shí)現(xiàn)來(lái)決定。Stream就是一般的文件存儲(chǔ)了，一般用來(lái)存存圖片啊啥的，適用于比較經(jīng)常使用，然而數(shù)據(jù)量又不算非常大的那種。

• 數(shù)據(jù)庫(kù)存儲(chǔ)
  數(shù)據(jù)庫(kù)存儲(chǔ)的話，花樣就比較多了。蘋(píng)果自帶了一個(gè)Core Data，當(dāng)然業(yè)界也有無(wú)數(shù)替代方案可選，不過(guò)真正用在iOS領(lǐng)域的除了Core Data外，就是FMDB比較多了。數(shù)據(jù)庫(kù)方案主要是為了便于增刪改查，當(dāng)數(shù)據(jù)有狀態(tài)和類別的時(shí)候最好還是采用數(shù)據(jù)庫(kù)方案比較好，而且尤其是當(dāng)這些狀態(tài)和類別都是強(qiáng)業(yè)務(wù)相關(guān)的時(shí)候，就更加要采用數(shù)據(jù)庫(kù)方案了。因?yàn)槟悴豢赡芡ㄟ^(guò)文件系統(tǒng)遍歷文件去甄別你需要獲取的屬于某個(gè)狀態(tài)或類別的數(shù)據(jù)，這么做成本就太大了。當(dāng)然，特別大量的數(shù)據(jù)也不適合直接存儲(chǔ)數(shù)據(jù)庫(kù)，比如圖片或者文章這樣的數(shù)據(jù)，一般來(lái)說(shuō)，都是數(shù)據(jù)庫(kù)存一個(gè)文件名，然后這個(gè)文件名指向的是某個(gè)圖片或者文章的文件。如果真的要做全文索引這種需求，建議最好還是掛個(gè)API丟到服務(wù)端去做。

功能組件化

功能組件化：將擁有獨(dú)立功能的代碼從系統(tǒng)中進(jìn)行抽象并剝離，再以“插件”的形式插回原有系統(tǒng)中。剝離出功能組件，降低系統(tǒng)中模塊與模塊之間的耦和性，同時(shí)提高APP之間代碼的復(fù)用性。比如，廣告作為很多公司盈利的主要來(lái)源，抽取出一個(gè)廣告插件，使用的地方靈活配置絕對(duì)是所有人的做法。
當(dāng)然，組件化一般情況下都會(huì)分為公有組件和業(yè)務(wù)組件。

- 公有組件

指的是封裝得比較好的一些SDK，包括一些第三方組件和自己內(nèi)部使用的組件，比如人人稱道的AFNetworking、SDwebImage，都是這類組件的代表。

- 業(yè)務(wù)組件

則定義為包含了一系列業(yè)務(wù)功能的整體，例如登錄業(yè)務(wù)組件，注冊(cè)業(yè)務(wù)組件，賬戶業(yè)務(wù)組件即為此類組件的典型代表。對(duì)于業(yè)務(wù)組件，前期一般多會(huì)在使用的頁(yè)面生成class、傳遞參數(shù)、跳轉(zhuǎn)頁(yè)面。一種有效改良的方法是“采取了業(yè)務(wù)模塊注冊(cè)機(jī)制”來(lái)解除耦合，每個(gè)業(yè)務(wù)模塊對(duì)外提供相應(yīng)的業(yè)務(wù)接口和短鏈接，短鏈接專門(mén)用一個(gè)類來(lái)映射對(duì)應(yīng)的處理方法，靈活方便。而在業(yè)務(wù)組件，即業(yè)務(wù)模塊的內(nèi)部，則可以根據(jù)不同開(kāi)發(fā)人員的偏好，來(lái)實(shí)現(xiàn)不同的代碼架構(gòu)。如上面討論的MVVM, MVP等，都可以在模塊內(nèi)部進(jìn)行而不影響整體系統(tǒng)架構(gòu)。

- 組件化示例

項(xiàng)目的初期，不管用那種架構(gòu)，我們經(jīng)常會(huì)采用模塊之間互相調(diào)用，甚至模塊劃分不清晰，如圖：

造成嚴(yán)重耦合，為了解決上面的問(wèn)題，可以考慮加一個(gè)中間層來(lái)協(xié)調(diào)模塊間的調(diào)用，所有的模塊間的調(diào)用都會(huì)經(jīng)過(guò)中間層中轉(zhuǎn)。如下：

• 蘑菇街MGJRouter
• casatwy組件化
• 滴滴組件化架構(gòu)
• 淘寶組件化架構(gòu)

Hybrid

移動(dòng)APP的開(kāi)發(fā)有兩種不同的路線，Native APP和Web APP。這兩種路線的區(qū)別類似于PC時(shí)代開(kāi)發(fā)應(yīng)用程序時(shí)的C/S架構(gòu)和 B/S架構(gòu)。

• Native APP
  即所有的程序都由本地組件渲染完成。這類APP優(yōu)點(diǎn)是顯而易見(jiàn)的，渲染速度快、用戶體驗(yàn)好；缺點(diǎn)同時(shí)也十分突出：出現(xiàn)了錯(cuò)誤一定要等待下一次用戶進(jìn)行APP更新才能夠修復(fù)。

• Web APP
  優(yōu)點(diǎn)恰好就是Native APP的缺點(diǎn)所在，其頁(yè)面全部采用H5撰寫(xiě)并存放在服務(wù)器端。每次進(jìn)行頁(yè)面渲染時(shí)都從服務(wù)器請(qǐng)求最新的頁(yè)面。一旦頁(yè)面有錯(cuò)誤服務(wù)器端進(jìn)行更新便能立刻解決。不過(guò)其弊端也容易窺見(jiàn)：每次頁(yè)面都需要請(qǐng)求服務(wù)器，造成渲染時(shí)等待時(shí)間過(guò)長(zhǎng)，從而導(dǎo)致的用戶體驗(yàn)不夠完美，并且性能上較Native APP慢了1-2個(gè)數(shù)量級(jí)；與此同時(shí)還會(huì)導(dǎo)致更多的用戶流量消耗。另一個(gè)缺點(diǎn)則在于，Web APP在移動(dòng)端上調(diào)用本地的硬件設(shè)備存在一定的不便。不過(guò)這些弊端也都有相應(yīng)的解決方案，如PhoneGap將網(wǎng)頁(yè)提前打包在本地以減少網(wǎng)絡(luò)的請(qǐng)求時(shí)間；同時(shí)也提供一系列的插件來(lái)訪問(wèn)本地的硬件設(shè)備。然而，盡管如此，其渲染速度上還是會(huì)稍微存在一定的差距。

• Hybrid APP
  則是綜合了二者優(yōu)缺點(diǎn)的解決方案。純粹展示性的模塊會(huì)更適合使用Web頁(yè)面來(lái)達(dá)到渲染的目的；而更多的數(shù)據(jù)操作性、動(dòng)畫(huà)渲染性的模塊則更適合采用Native的方式。
  在Hot Patch被蘋(píng)果爸爸強(qiáng)制截?cái)啵琀ybrid會(huì)被推向一個(gè)新高度。是的，完全無(wú)法想象，出現(xiàn)bug，特別是重大問(wèn)題后，你只能束手無(wú)策的提交新版本，耐心等待審核人員通過(guò)，告知用戶升級(jí)新版本。而典型的Hybrid，得到行業(yè)認(rèn)可的是Facebook開(kāi)源的React-Native，當(dāng)然，目前國(guó)產(chǎn)大公司也有很多建樹(shù)，某寶的weex，我司已經(jīng)開(kāi)始大量投入使用（略微擔(dān)心蘋(píng)果親爸整出什么幺蛾子??）。
  也有很多H5直接和Native交互，以JSBridge的方式連接的方案進(jìn)行動(dòng)態(tài)部署，有名的CTJSBridge。

設(shè)計(jì)模式

設(shè)計(jì)模式可以通俗的理解為實(shí)現(xiàn)/解決某些問(wèn)題，而形成的解決方案規(guī)范。增加代碼的可重用性，讓代碼能更容易理解和可靠。我們通常說(shuō)所的代理模式、迭代器模式、策略模式就屬于這一類。對(duì)各種設(shè)計(jì)模式的了解可以幫助我們更快的解決編程過(guò)程中遇到的問(wèn)題。
設(shè)計(jì)模式：設(shè)計(jì)模式主要分三個(gè)類型:創(chuàng)建型、結(jié)構(gòu)型和行為型。傳送門(mén)-23種設(shè)計(jì)模式詳解
創(chuàng)建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結(jié)構(gòu)型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問(wèn)者模式、中介者模式、解釋器模式。
其實(shí)還有兩類：并發(fā)型模式和線程池模式。

其中iOS主要重點(diǎn)用到的是以下幾種：

• 單例模式
  當(dāng)某個(gè)對(duì)象在整個(gè)程序中我們只需要一個(gè)，并且我們需要在不同的地方調(diào)用這個(gè)對(duì)象，獲取其中的屬性資源。這種時(shí)候我們就需要用到單例模式這種設(shè)計(jì)模式。
  示例：
  UIApplication類提供了 ＋sharedAPplication方法創(chuàng)建和獲取UIApplication單例
  NSBundle類提供了 +mainBunle方法獲取NSBundle單例
  NSFileManager類提供了 ＋defaultManager方法創(chuàng)建和獲得NSFileManager單例。（PS：有些時(shí)候我們得放棄使用單例模式，使用－init方法去實(shí)現(xiàn)一個(gè)新的實(shí)例，比如使用委托時(shí)）
  NSNotificationCenter提供了 ＋defaultCenter方法創(chuàng)建和獲取NSNotificationCenter單例（PS：該類還遵循了另一個(gè)重要的設(shè)計(jì)模式：觀察者模式）
  NSUserDefaults類提供了 ＋defaultUserDefaults方法去創(chuàng)建和獲取NSUserDefaults單例

** 一般我們習(xí)慣在定義方法share中使用dispatch_once函數(shù)（這個(gè)函數(shù)的作用就是保證block）來(lái)保證單例模式在整個(gè)程序中只被創(chuàng)建一次。但是之前看到有個(gè)同學(xué)是覆寫(xiě)+(instancetype)allocWithZone:(struct _NSZone *)zone方法中添加代碼，保證只被創(chuàng)建一次。原因是別人可能并不知道你是單例，在生成的時(shí)候用[[class alloc]init]的形式，allocWithZone能保證不管哪種形式都能確保是單例。

• 觀察者模式
  一個(gè)對(duì)象狀態(tài)改變，通知正在對(duì)他進(jìn)行觀察的對(duì)象，這些對(duì)象根據(jù)各自要求做出相應(yīng)的改變。操作對(duì)象向被觀察者對(duì)象投送消息，使得被觀察者的狀態(tài)得以改變，在此之前已經(jīng)有觀察者向被觀察對(duì)象注冊(cè)，訂閱它的廣播，現(xiàn)在被觀察對(duì)象將自己狀態(tài)發(fā)生改變的消息廣播出來(lái)，觀察者接收到消息各自做出應(yīng)變。
  示例：
  KVO(Key-Value-Observing)機(jī)制：
  通知(notification)機(jī)制，NSNotificationCenter

• 代理模式
  就像是java中的接口，類可以實(shí)現(xiàn)或不實(shí)現(xiàn)協(xié)議（接口）中的方法。
  示例：
  UITableViewDelegate UITableViewDataSource

• 策略模式

• 簡(jiǎn)單工廠

“簡(jiǎn)單工廠模式是屬于創(chuàng)建型模式，又叫做靜態(tài)工廠方法（Static Factory Method）模式，但不屬于23種GOF設(shè)計(jì)模式之一。簡(jiǎn)單工廠模式是由一個(gè)工廠對(duì)象決定創(chuàng)建出哪一種產(chǎn)品類的實(shí)例。簡(jiǎn)單工廠模式是工廠模式家族中最簡(jiǎn)單實(shí)用的模式，可以理解為是不同工廠模式的一個(gè)特殊實(shí)現(xiàn)?！薄俣劝倏?br> 簡(jiǎn)單工廠詳解及示例

• 工廠模式

工廠模式是我們最常用的實(shí)例化對(duì)象模式了，是用工廠方法代替new操作的一種模式。著名的Jive論壇 ,就大量使用了工廠模式，工廠模式在Java程序系統(tǒng)可以說(shuō)是隨處可見(jiàn)。因?yàn)楣S模式就相當(dāng)于創(chuàng)建實(shí)例對(duì)象的new，我們經(jīng)常要根據(jù)類Class生成實(shí)例對(duì)象，如A a=new A() 工廠模式也是用來(lái)創(chuàng)建實(shí)例對(duì)象的，所以以后new時(shí)就要多個(gè)心眼，是否可以考慮使用工廠模式，雖然這樣做，可能多做一些工作，但會(huì)給你系統(tǒng)帶來(lái)更大的可擴(kuò)展性和盡量少的修改量。---百度百科
定義創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類。工廠方法使得一個(gè)類的實(shí)例化延遲到子類。
工廠方式應(yīng)該算是我們經(jīng)常都會(huì)使用到的一種設(shè)計(jì)模式了，例如OC中的NSNumber，NSNumber可以提供int、BOOL、Float等相關(guān)類型的工廠方法來(lái)生產(chǎn)基于特定接口的不同類型對(duì)象。工廠模式的直觀意義可以理解為：通過(guò)固定工廠，生產(chǎn)不同形式的單一物品。例如我有一個(gè)輪胎工廠，我可以在工廠中生產(chǎn)適用于汽車、卡車、摩托車等適應(yīng)的輪胎。
工廠模式詳解及示例

• 抽象工廠模式

抽象工廠模式是所有形態(tài)的工廠模式中最為抽象和最具一般性的一種形態(tài)。抽象工廠模式是指當(dāng)有多個(gè)抽象角色時(shí)，使用的一種工廠模式。抽象工廠模式可以向客戶端提供一個(gè)接口，使客戶端在不必指定產(chǎn)品的具體的情況下，創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對(duì)象。根據(jù)里氏替換原則，任何接受父類型的地方，都應(yīng)當(dāng)能夠接受子類型。因此，實(shí)際上系統(tǒng)所需要的，僅僅是類型與這些抽象產(chǎn)品角色相同的一些實(shí)例，而不是這些抽象產(chǎn)品的實(shí)例。換言之，也就是這些抽象產(chǎn)品的具體子類的實(shí)例。工廠類負(fù)責(zé)創(chuàng)建抽象產(chǎn)品的具體子類的實(shí)例。---[百度百科]

• 適配器模式

在計(jì)算機(jī)編程中，適配器模式（有時(shí)候也稱包裝樣式或者包裝）將一個(gè)類的接口適配成用戶所期待的。一個(gè)適配允許通常因?yàn)榻涌诓患嫒荻荒茉谝黄鸸ぷ鞯念惞ぷ髟谝黄?，做法是將類自己的接口包裹在一個(gè)已存在的類中。---百度百科
簡(jiǎn)而言之，就是引入一系列的操作取代之前對(duì)應(yīng)的操作，同時(shí)又不影響以前的功能。
適配器模式模式詳解及示例

一篇關(guān)于“幾種設(shè)計(jì)模式對(duì)比”比較好的講解：傳送門(mén)