1.描述一下iOS SDK中如何實(shí)現(xiàn)MVC的開(kāi)發(fā)模式

MVC是模型乍楚、視圖睡互、控制開(kāi)發(fā)模式玻淑。
對(duì)于iOS SDK：
所有的用戶數(shù)據(jù)都是模型層栗柒，它應(yīng)該獨(dú)立于視圖礁扮。
所有的View都是視圖層的，它應(yīng)該獨(dú)立于模型層，由視圖控制層來(lái)控制太伊。
所有的ViewController都是控制層负蠕，由它負(fù)責(zé)控制視圖，訪問(wèn)模型數(shù)據(jù)倦畅。

2遮糖、請(qǐng)簡(jiǎn)述你對(duì)MVC設(shè)計(jì)模式的理解

簡(jiǎn)要：MVC模式考慮三種對(duì)象：模型對(duì)象、視圖對(duì)象和控制器對(duì)象叠赐。
模型對(duì)象負(fù)責(zé)應(yīng)用程序的數(shù)據(jù)和定義操作數(shù)據(jù)的邏輯欲账；
視圖對(duì)象知道如何顯示應(yīng)用程序的模型數(shù)據(jù)；
控制器對(duì)象是M與V之間的協(xié)調(diào)者.

3芭概、描述一下iOS SDK中如何實(shí)現(xiàn)MVC的開(kāi)發(fā)模式

MVC是模型赛不、視圖、控制開(kāi)發(fā)模式罢洲，對(duì)于iOS SDK踢故，所有的View都是視圖層的，它應(yīng)該獨(dú)立于模型層惹苗，由視圖控制層來(lái)控制殿较。所有的用戶數(shù)據(jù)都是模型層，它應(yīng)該獨(dú)立于視圖桩蓉。所有的ViewController都是控制層淋纲，由它負(fù)責(zé)控制視圖，訪問(wèn)模型數(shù)據(jù)院究。

4洽瞬、MVC優(yōu)點(diǎn)不正確的是 D

A 低耦合性
B 高重用性和可適用性
C 較低的生命周期成本
D 代碼高效率

5、哪些類不適合使用單例模式业汰？即使他們?cè)谥芷谥兄粫?huì)出現(xiàn)一次伙窃。

單例是只有一個(gè)實(shí)例，并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例样漆。
哪些類不適合<不知>

6为障、MVC模式的理解

答:
MVC，全稱Model（模型）-View（視圖）-Controller（控制器）氛濒，這是一種開(kāi)發(fā)模式产场，他的好處是可以將界面和業(yè)務(wù)邏輯分離鹅髓。
Model（模型）：
是程序的主體部分舞竿，主要包含業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)邏輯。在模型層窿冯，還會(huì)涉及到用戶發(fā)布的服務(wù)骗奖，在服務(wù)中會(huì)根據(jù)不同的業(yè)務(wù)需求，更新業(yè)務(wù)模型中的數(shù)據(jù)。
View(視圖）：
是程序呈現(xiàn)給用戶的部分执桌，是用戶和程序交互的接口鄙皇，用戶會(huì)根據(jù)具體的業(yè)務(wù)需求，在View視圖層輸入自己特定的業(yè)務(wù)數(shù)據(jù)仰挣，并通過(guò)界面的事件交互伴逸，將對(duì)應(yīng)的輸入?yún)?shù)提交給后臺(tái)控制器進(jìn)行處理。
Controller（控制器）：
Controller是用來(lái)處理用戶輸入數(shù)據(jù)膘壶，已經(jīng)更新業(yè)務(wù)模型的部分错蝴。控制器中接收了用戶與界面交互時(shí)傳遞過(guò)來(lái)的數(shù)據(jù)颓芭，并根據(jù)數(shù)據(jù)業(yè)務(wù)邏輯來(lái)執(zhí)行服務(wù)的調(diào)用和更新業(yè)務(wù)模型的數(shù)據(jù)和狀態(tài)顷锰。

7、談?wù)勀懔私獾脑O(shè)計(jì)模式亡问，你用過(guò)哪些官紫，他們的優(yōu)缺點(diǎn)。

（一）代理模式
應(yīng)用場(chǎng)景：當(dāng)一個(gè)類的某些功能需要由別的類來(lái)實(shí)現(xiàn)州藕，但是又不確定具體會(huì)是哪個(gè)類實(shí)現(xiàn)束世。
優(yōu)勢(shì)：解耦合
敏捷原則：開(kāi)放-封閉原則
實(shí)例：
tableview的數(shù)據(jù)源delegate，通過(guò)和protocol的配合床玻，完成委托訴求良狈。
列表row個(gè)數(shù)delegate
自定義的delegate

（二）觀察者模式
應(yīng)用場(chǎng)景：一般為model層，對(duì)controller和view進(jìn)行的通知方式笨枯，不關(guān)心誰(shuí)去接收薪丁，只負(fù)責(zé)發(fā)布信息。
優(yōu)勢(shì)：解耦合
敏捷原則：接口隔離原則馅精，開(kāi)放-封閉原則
實(shí)例：
Notification通知中心严嗜，注冊(cè)通知中心，任何位置可以發(fā)送消息洲敢，注冊(cè)觀察者的對(duì)象可以接收漫玄。
kvo，鍵值對(duì)改變通知的觀察者压彭，平時(shí)基本沒(méi)用過(guò)睦优。

（三）MVC模式
應(yīng)用場(chǎng)景：是一中非常古老的設(shè)計(jì)模式，通過(guò)數(shù)據(jù)模型壮不，控制器邏輯汗盘，視圖展示將應(yīng)用程序進(jìn)行邏輯劃分。
優(yōu)勢(shì)：使系統(tǒng)询一，層次清晰隐孽，職責(zé)分明癌椿，易于維護(hù)
敏捷原則：對(duì)擴(kuò)展開(kāi)放-對(duì)修改封閉
實(shí)例：
model-即數(shù)據(jù)模型，view-視圖展示菱阵，controller進(jìn)行UI展現(xiàn)和數(shù)據(jù)交互的邏輯控制踢俄。

（四）單例模式
應(yīng)用場(chǎng)景：確保程序運(yùn)行期某個(gè)類，只有一份實(shí)例晴及，用于進(jìn)行資源共享控制都办。
優(yōu)勢(shì)：使用簡(jiǎn)單，延時(shí)求值虑稼，易于跨模塊
敏捷原則：?jiǎn)我宦氊?zé)原則
實(shí)例：
[UIApplication sharedApplication]脆丁。
注意事項(xiàng)：確保使用者只能通過(guò)getInstance方法才能獲得，單例類的唯一實(shí)例动雹。
java，C++中使其沒(méi)有公有構(gòu)造函數(shù)歼培，私有化并覆蓋其構(gòu)造函數(shù)钾虐。
object c中，重寫(xiě)allocWithZone方法，保證即使用戶用alloc方法直接創(chuàng)建單例類的實(shí)例，
返回的也只是此單例類的唯一靜態(tài)變量疟赊。

（五）策略模式
應(yīng)用場(chǎng)景：定義算法族异赫，封裝起來(lái)靠抑，使他們之間可以相互替換。
優(yōu)勢(shì)：使算法的變化獨(dú)立于使用算法的用戶
敏捷原則：接口隔離原則；多用組合，少用繼承；針對(duì)接口編程昔脯，而非實(shí)現(xiàn)碱鳞。
實(shí)例：
排序算法，NSArray的sortedArrayUsingSelector崩泡；
經(jīng)典的鴨子會(huì)叫禁荒，會(huì)飛案例。

注意事項(xiàng)：

1角撞，剝離類中易于變化的行為呛伴，通過(guò)組合的方式嵌入抽象基類
2勃痴，變化的行為抽象基類為，所有可變變化的父類
3热康，用戶類的最終實(shí)例沛申，通過(guò)注入行為實(shí)例的方式，設(shè)定易變行為
防止了繼承行為方式姐军，導(dǎo)致無(wú)關(guān)行為污染子類铁材。完成了策略封裝和可替換性奕锌。

（六）工廠模式
應(yīng)用場(chǎng)景：工廠方式創(chuàng)建類的實(shí)例著觉，多與proxy模式配合，創(chuàng)建可替換代理類惊暴。
優(yōu)勢(shì)：易于替換饼丘，面向抽象編程，application只與抽象工廠和易變類的共性抽象類發(fā)生調(diào)用關(guān)系辽话。
敏捷原則：DIP依賴倒置原則
實(shí)例：
項(xiàng)目部署環(huán)境中依賴多個(gè)不同類型的數(shù)據(jù)庫(kù)時(shí)葬毫，需要使用工廠配合proxy完成易用性替換
注意事項(xiàng)：
項(xiàng)目初期，軟件結(jié)構(gòu)和需求都沒(méi)有穩(wěn)定下來(lái)時(shí)屡穗，不建議使用此模式贴捡，因?yàn)槠淞觿?shì)也很明顯，增加了代碼的復(fù)雜度村砂，增加了調(diào)用層次烂斋，增加了內(nèi)存負(fù)擔(dān)。所以要注意防止模式的濫用础废。

8汛骂、mvc設(shè)計(jì)模式是什么?你還熟悉什么設(shè)計(jì)模式

答:系統(tǒng)分為三個(gè)部分: Model. View. Controller.在cocoa中,你的程序中的每一個(gè)object
(對(duì)象)都將明顯地僅屬于這三部分中的一個(gè)，而完全不屬于另外兩個(gè)评腺。MVC課一幫助確保幫助實(shí)現(xiàn)程序最大程度的可重用性帘瞭，各MVC元素彼此獨(dú)立運(yùn)作，通過(guò)分開(kāi)這些元素蒿讥，可以構(gòu)建可維護(hù)蝶念，可獨(dú)立更新的程序組建。
Delegate設(shè)計(jì)模式芋绸；
Target-action設(shè)計(jì)模式媒殉；
單例模式；

9摔敛、請(qǐng)至少列舉5個(gè)常用的設(shè)計(jì)模式廷蓉。

1）代理模式
2）觀察者模式
3）MVC模式
4）單例模式
5）工廠模式

10、談?wù)勀懔私獾脑O(shè)計(jì)模式,你用過(guò)哪些,他們的缺點(diǎn)

1.MVC:

優(yōu)點(diǎn)：
1马昙、開(kāi)發(fā)人員可以只關(guān)注整個(gè)結(jié)構(gòu)中的其中某一層桃犬；
2刹悴、可以很容易的用新的實(shí)現(xiàn)來(lái)替換原有層次的實(shí)現(xiàn)；
3攒暇、可以降低層與層之間的依賴土匀；
4、有利于標(biāo)準(zhǔn)化扯饶；
5恒削、利于各層邏輯的復(fù)用池颈。

缺點(diǎn):
1尾序、降低了系統(tǒng)的性能。這是不言而喻的躯砰。如果不采用分層式結(jié)構(gòu)每币，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫(kù)，以此獲取相應(yīng)的數(shù)據(jù)琢歇，如今卻必須通過(guò)中間層來(lái)完成兰怠。
2、有時(shí)會(huì)導(dǎo)致級(jí)聯(lián)的修改李茫。這種修改尤其體現(xiàn)在自上而下的方向揭保。如果在表示層中需要增加一個(gè)功能，為保證其設(shè)計(jì)符合分層式結(jié)構(gòu)魄宏，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層中都增加相應(yīng)的代碼秸侣。

2.觀察者模式
優(yōu)點(diǎn)：
1、觀察者模式在被觀察者和觀察者之間建立一個(gè)抽象的耦合宠互。被觀察者角色所知道的只是一個(gè)具體觀察者列表味榛，每一個(gè)具體觀察者都符合一個(gè)抽象觀察者的接口。被觀察者并不認(rèn)識(shí)任何一個(gè)具體觀察者予跌，它只知道它們都有一個(gè)共同的接口搏色。
由于被觀察者和觀察者沒(méi)有緊密地耦合在一起，因此它們可以屬于不同的抽象化層次券册。如果被觀察者和觀察者都被扔到一起频轿，那么這個(gè)對(duì)象必然跨越抽象化和具體化層次。
2烁焙、觀察者模式支持廣播通訊略吨。被觀察者會(huì)向所有的登記過(guò)的觀察者發(fā)出通知，

缺點(diǎn)：
1考阱、如果一個(gè)被觀察者對(duì)象有很多的直接和間接的觀察者的話翠忠，將所有的觀察者都通知到會(huì)花費(fèi)很多時(shí)間。
2乞榨、如果在被觀察者之間有循環(huán)依賴的話秽之，被觀察者會(huì)觸發(fā)它們之間進(jìn)行循環(huán)調(diào)用当娱，導(dǎo)致系統(tǒng)崩潰。在使用觀察者模式是要特別注意這一點(diǎn)考榨。
3跨细、如果對(duì)觀察者的通知是通過(guò)另外的線程進(jìn)行異步投遞的話，系統(tǒng)必須保證投遞是以自恰的方式進(jìn)行的河质。
4冀惭、雖然觀察者模式可以隨時(shí)使觀察者知道所觀察的對(duì)象發(fā)生了變化，但是觀察者模式?jīng)]有相應(yīng)的機(jī)制使觀察者知道所觀察的對(duì)象是怎么發(fā)生變化的掀鹅。

3.單例模式:
主要優(yōu)點(diǎn)：
1散休、提供了對(duì)唯一實(shí)例的受控訪問(wèn)。
2乐尊、由于在系統(tǒng)內(nèi)存中只存在一個(gè)對(duì)象戚丸，因此可以節(jié)約系統(tǒng)資源，對(duì)于一些需要頻繁創(chuàng)建和銷毀的對(duì)象單例模式無(wú)疑可以提高系統(tǒng)的性能扔嵌。
3限府、允許可變數(shù)目的實(shí)例。

主要缺點(diǎn)：
1痢缎、由于單利模式中沒(méi)有抽象層胁勺，因此單例類的擴(kuò)展有很大的困難。
2独旷、單例類的職責(zé)過(guò)重署穗，在一定程度上違背了“單一職責(zé)原則”。
3势告、濫用單例將帶來(lái)一些負(fù)面問(wèn)題蛇捌，如為了節(jié)省資源將數(shù)據(jù)庫(kù)連接池對(duì)象設(shè)計(jì)為的單例類，可能會(huì)導(dǎo)致共享連接池對(duì)象的程序過(guò)多而出現(xiàn)連接池溢出咱台；如果實(shí)例化的對(duì)象長(zhǎng)時(shí)間不被利用络拌，系統(tǒng)會(huì)認(rèn)為是垃圾而被回收，這將導(dǎo)致對(duì)象狀態(tài)的丟失回溺。

11春贸、談?wù)凪VC設(shè)計(jì)模式的優(yōu)缺點(diǎn)

編程以來(lái)就一直被灌輸MVC設(shè)計(jì)模式，具體MVC使用到底好在哪里遗遵？又有那些不足之處萍恕，可以通過(guò)下面的介紹得以了解。

一车要、mvc原理
mvc是一種程序開(kāi)發(fā)設(shè)計(jì)模式,它實(shí)現(xiàn)了顯示模塊與功能模塊的分離允粤。提高了程序的可維護(hù)性、可移植性、可擴(kuò)展性與可重用性类垫，降低了程序的開(kāi)發(fā)難度司光。它主要分模型、視圖悉患、控制器三層残家。
1、模型(model)它是應(yīng)用程序的主體部分售躁，主要包括業(yè)務(wù)邏輯模塊（web項(xiàng)目中的Action,dao類）和數(shù)據(jù)模塊（pojo類）坞淮。模型與數(shù)據(jù)格式無(wú)關(guān)，這樣一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)陪捷。由于應(yīng)用于模型的代碼只需寫(xiě)一次就可以被多個(gè)視圖重用回窘，所以減少了代碼的重復(fù)性
2、視圖(view) 用戶與之交互的界面揩局、在web中視圖一般由jsp,html組成
3毫玖、控制器(controller)接收來(lái)自界面的請(qǐng)求掀虎，并交給模型進(jìn)行處理凌盯，在這個(gè)過(guò)程中控制器不做任何處理只是起到了一個(gè)連接的做用.

二、MVC的優(yōu)點(diǎn)
1烹玉、可以為一個(gè)模型在運(yùn)行時(shí)同時(shí)建立和使用多個(gè)視圖驰怎。變化-傳播機(jī)制可以確保所有相關(guān)的視圖及時(shí)得到模型數(shù)據(jù)變化，從而使所有關(guān)聯(lián)的視圖和控制器做到行為同步二打。

2、視圖與控制器的可接插性，允許更換視圖和控制器對(duì)象词裤，而且可以根據(jù)需求動(dòng)態(tài)的打開(kāi)或關(guān)閉训措、甚至在運(yùn)行期間進(jìn)行對(duì)象替換。

3瑞信、模型的可移植性厉颤。因?yàn)槟Ｐ褪仟?dú)立于視圖的，所以可以把一個(gè)模型獨(dú)立地移植到新的平臺(tái)工作凡简。需要做的只是在新平臺(tái)上對(duì)視圖和控制器進(jìn)行新的修改逼友。

4、潛在的框架結(jié)構(gòu)秤涩≈钠颍可以基于此模型建立應(yīng)用程序框架，不僅僅是用在設(shè)計(jì)界面的設(shè)計(jì)中筐眷。

三黎烈、MVC的不足之處

1、增加了系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)的復(fù)雜性。對(duì)于簡(jiǎn)單的界面照棋，嚴(yán)格遵循MVC津畸，使模型、視圖與控制器分離必怜，會(huì)增加結(jié)構(gòu)的復(fù)雜性肉拓，并可能產(chǎn)生過(guò)多的更新操作，降低運(yùn)行效率梳庆。

2暖途、視圖與控制器間的過(guò)于緊密的連接。視圖與控制器是相互分離膏执，但確實(shí)聯(lián)系緊密的部件驻售，視圖沒(méi)有控制器的存在，其應(yīng)用是很有限的更米，反之亦然欺栗，這樣就妨礙了他們的獨(dú)立重用。

3征峦、視圖對(duì)模型數(shù)據(jù)的低效率訪問(wèn)迟几。依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)栏笆。對(duì)未變化數(shù)據(jù)的不必要的頻繁訪問(wèn)类腮，也將損害操作性能。

4蛉加、目前蚜枢，一般高級(jí)的界面工具或構(gòu)造器不支持模式。改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價(jià)是很高的针饥，從而造成MVC使用的困難厂抽。

24.談?wù)勀銓?duì)MVC開(kāi)發(fā)模式的理解及你是如何在iOS項(xiàng)目中采用MVC模式開(kāi)發(fā)的？
22.談?wù)勀銓?duì)代理設(shè)計(jì)模式的理解
13.你是怎么理解MVC的丁眼，在Cocoa中MVC是怎么實(shí)現(xiàn)的筷凤？
16.談一下你常用的一些設(shè)計(jì)模式及應(yīng)用場(chǎng)景