（一）代理模式
應(yīng)用場景：當(dāng)一個(gè)類的某些功能需要由別的類來實(shí)現(xiàn)，但是又不確定具體會是哪個(gè)類實(shí)現(xiàn)。
優(yōu)勢：解耦合
敏捷原則：開放-封閉原則
實(shí)例：tableview的 數(shù)據(jù)源delegate贰军，通過和protocol的配合丽蝎，完成委托訴求。
列表row個(gè)數(shù)delegate
自定義的delegate
（二）觀察者模式
應(yīng)用場景：一般為model層對霎桅，controller和view進(jìn)行的通知方式，不關(guān)心誰去接收，只負(fù)責(zé)發(fā)布信息沽一。
優(yōu)勢：解耦合
敏捷原則：接口隔離原則，開放-封閉原則
實(shí)例：Notification通知中心漓糙，注冊通知中心铣缠，任何位置可以發(fā)送消息，注冊觀察者的對象可以接收昆禽。
kvo蝗蛙，鍵值對改變通知的觀察者，平時(shí)基本沒用過醉鳖。
（三）MVC模式
應(yīng)用場景：是一中非常古老的設(shè)計(jì)模式捡硅，通過數(shù)據(jù)模型，控制器邏輯盗棵，視圖展示將應(yīng)用程序進(jìn)行邏輯劃分壮韭。
優(yōu)勢：使系統(tǒng)，層次清晰纹因，職責(zé)分明喷屋，易于維護(hù)
敏捷原則：對擴(kuò)展開放-對修改封閉
實(shí)例：model-即數(shù)據(jù)模型，view-視圖展示辐怕，controller進(jìn)行UI展現(xiàn)和數(shù)據(jù)交互的邏輯控制逼蒙。
（四）單例模式
應(yīng)用場景：確保程序運(yùn)行期某個(gè)類，只有一份實(shí)例寄疏，用于進(jìn)行資源共享控制是牢。
優(yōu)勢：使用簡單，延時(shí)求值陕截，易于跨模塊
敏捷原則：單一職責(zé)原則
實(shí)例：[UIApplication sharedApplication]驳棱。
注意事項(xiàng)：確保使用者只能通過 getInstance方法才能獲得，單例類的唯一實(shí)例农曲。
java社搅，C++中使其沒有公有構(gòu)造函數(shù)驻债，私有化并覆蓋其構(gòu)造函數(shù)。
object c中形葬，重寫allocWithZone方法合呐，保證即使用戶用 alloc方法直接創(chuàng)建單例類的實(shí)例。
返回的也只是此單例類的唯一靜態(tài)變量笙以。
（五）策略模式
應(yīng)用場景：定義算法族淌实，封裝起來，使他們之間可以相互替換猖腕。
優(yōu)勢：使算法的變化獨(dú)立于使用算法的用戶
敏捷原則：接口隔離原則拆祈；多用組合，少用繼承倘感；針對接口編程放坏，而非實(shí)現(xiàn)。
實(shí)例：排序算法老玛，NSArray的sortedArrayUsingSelector淤年；經(jīng)典的鴨子會叫，會飛案例逻炊。
注意事項(xiàng)：
1互亮，剝離類中易于變化的行為，通過組合的方式嵌入抽象基類
2余素，變化的行為抽象基類為豹休，所有可變變化的父類
3，用戶類的最終實(shí)例桨吊，通過注入行為實(shí)例的方式威根，設(shè)定易變行為
防止了繼承行為方式，導(dǎo)致無關(guān)行為污染子類视乐。完成了策略封裝和可替換性洛搀。
（六）工廠模式
應(yīng)用場景：工廠方式創(chuàng)建類的實(shí)例，多與proxy模式配合佑淀，創(chuàng)建可替換代理類留美。
優(yōu)勢：易于替換，面向抽象編程伸刃，application只與抽象工廠和易變類的共性抽象類發(fā)生調(diào)用關(guān)系谎砾。
敏捷原則：DIP依賴倒置原則
實(shí)例：項(xiàng)目部署環(huán)境中依賴多個(gè)不同類型的數(shù)據(jù)庫時(shí)，需要使用工廠配合proxy完成易用性替換
注意事項(xiàng)：
項(xiàng)目初期捧颅，軟件結(jié)構(gòu)和需求都沒有穩(wěn)定下來時(shí)景图，不建議使用此模式，因?yàn)槠淞觿菀埠苊黠@碉哑；
增加了代碼的復(fù)雜度挚币，增加了調(diào)用層次亮蒋，增加了內(nèi)存負(fù)擔(dān)。所以要注意防止模式的濫用妆毕。
單例會有什么弊端慎玖？
主要優(yōu)點(diǎn)：
1、提供了對唯一實(shí)例的受控訪問笛粘。
2凄吏、由于在系統(tǒng)內(nèi)存中只存在一個(gè)對象，因此可以節(jié)約系統(tǒng)資源闰蛔，對于一些需要頻繁創(chuàng)建和銷毀的對象單例模式無疑可以提高系統(tǒng)的性能。
3图柏、允許可變數(shù)目的實(shí)例序六。
主要缺點(diǎn)：
1、由于單利模式中沒有抽象層蚤吹，因此單例類的擴(kuò)展有很大的困難例诀。
2、單例類的職責(zé)過重裁着，在一定程度上違背了“單一職責(zé)原則”繁涂。
3、濫用單例將帶來一些負(fù)面問題二驰，如為了節(jié)省資源將數(shù)據(jù)庫連接池對象設(shè)計(jì)為的單例類扔罪，可能會導(dǎo)致共享連接池對象的程序過多而出現(xiàn)連接池溢出；如果實(shí)例化的對象長時(shí)間不被利用桶雀，系統(tǒng)會認(rèn)為是垃圾而被回收矿酵，這將導(dǎo)致對象狀態(tài)的丟失。
