⑨ 設(shè)計(jì)模式相關(guān)面試題
一.編程中的六大設(shè)計(jì)原則？
1.單一職責(zé)原則
通俗地講就是一個(gè)類只做一件事
-
CALayer：動(dòng)畫和視圖的顯示。 -
UIView：只負(fù)責(zé)事件傳遞、事件響應(yīng)。
2.開閉原則
對(duì)修改關(guān)閉，對(duì)擴(kuò)展開放。
要考慮到后續(xù)的擴(kuò)展性，而不是在原有的基礎(chǔ)上來回修改
3.接口隔離原則
使用多個(gè)專門的協(xié)議、而不是一個(gè)龐大臃腫的協(xié)議
UITableviewDelegateUITableViewDataSource
4.依賴倒置原則
抽象不應(yīng)該依賴于具體實(shí)現(xiàn)、具體實(shí)現(xiàn)可以依賴于抽象。
調(diào)用接口感覺不到內(nèi)部是如何操作的
5.里氏替換原則
父類可以被子類無縫替換，且原有的功能不受任何影響
例如 KVO
6.迪米特法則
一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其他對(duì)象盡可能少的了解，實(shí)現(xiàn)高聚合、低耦合
推薦文章
面向?qū)ο笤O(shè)計(jì)的六大設(shè)計(jì)原則（附 Demo 及 UML 類圖）- J_Knight_
二.如何設(shè)計(jì)一個(gè)圖片緩存框架？
可以模仿 SDWebImage 來實(shí)現(xiàn)。
構(gòu)成
- Manager
- 內(nèi)存緩存
- 磁盤緩存
- 網(wǎng)絡(luò)下載
- Code Manager
- 圖片解碼
- 圖片解壓縮
圖片的存儲(chǔ)是以圖片的單向 hash 值為 Key
內(nèi)存設(shè)計(jì)需要考慮的問題
存儲(chǔ)的 Size
因?yàn)閮?nèi)存的空間有限，我們針對(duì)不同尺寸的圖片，給出不同的方案
-
10K以下的50個(gè) -
100Kb以下的20個(gè) -
1000kb以上的10個(gè)
淘汰的策略
內(nèi)存的淘汰策略 采取 LRU（最近最少使用算法）
觸發(fā)淘汰策略的時(shí)機(jī)有三種
- 1.定期檢查（不建議，耗性能）
- 2.提高檢查觸發(fā)頻率（一定要注意開銷）
- 1.前后臺(tái)切換的時(shí)候
- 2.每次讀寫的時(shí)候
磁盤設(shè)計(jì)需要考慮的問題
存儲(chǔ)方式
大小限制（有固定的大?。?/p>
移除策略（可以設(shè)置為7天或者15天）
網(wǎng)絡(luò)設(shè)計(jì)需要考慮的問題
圖片請(qǐng)求的最大并發(fā)量
請(qǐng)求超時(shí)策略
請(qǐng)求優(yōu)先級(jí)
圖片解碼
應(yīng)用 策略模式，針對(duì) jpg、png、gif 等不同的圖片格式進(jìn)行解碼
圖片解碼的時(shí)機(jī)
- 在 子線程 圖片剛下載完時(shí)
- 在 子線程 剛從磁盤讀取完時(shí)
避免在主線程解壓縮、解碼，避免卡頓
三.如何設(shè)計(jì)一個(gè)時(shí)長(zhǎng)統(tǒng)計(jì)框架？
記錄器
- 頁面式記錄器
- 流式記錄器
- 自定義式
記錄管理者
- 內(nèi)存記錄緩存
- 磁盤存儲(chǔ)
- 上傳器
如何降低數(shù)據(jù)的丟失率？
- 定期寫入磁盤
- 每當(dāng)達(dá)到某個(gè)值的時(shí)候，就寫入磁盤
記錄上傳的時(shí)機(jī)
- 前后臺(tái)切換的時(shí)候可以上傳
- 從無網(wǎng)到有網(wǎng)切換的時(shí)候可以上傳
上傳時(shí)機(jī)的選擇
- 立即上傳
- 定時(shí)上傳
- 延時(shí)上傳
四.如何實(shí)現(xiàn) App 換膚（夜間模式）？
擴(kuò)利用 DKNightVersion 完成。
同時(shí)可以參考一下這篇文章。
五.iOS有哪些常見的設(shè)計(jì)模式?
代理模式
應(yīng)用場(chǎng)景：當(dāng)一個(gè)類的某些功能需要由別的類來實(shí)現(xiàn)，但是又不確定具體會(huì)是哪個(gè)類實(shí)現(xiàn)。
優(yōu)勢(shì)：解耦合
敏捷原則：開放-封閉原則觀察者模式
應(yīng)用場(chǎng)景：一般為model層對(duì)controller和view進(jìn)行的通知方式，不關(guān)心誰去接收，只負(fù)責(zé)發(fā)布信息。
優(yōu)勢(shì)：解耦合
敏捷原則：接口隔離原則，開放-封閉原則MVC模式
應(yīng)用場(chǎng)景：是一種非常古老的設(shè)計(jì)模式，通過數(shù)據(jù)模型，控制器邏輯，視圖展示將應(yīng)用程序進(jìn)行邏輯劃分。
優(yōu)勢(shì)：使系統(tǒng)，層次清晰，職責(zé)分明，易于維護(hù)
敏捷原則：對(duì)擴(kuò)展開放-對(duì)修改封閉單例模式
應(yīng)用場(chǎng)景：確保程序運(yùn)行期某個(gè)類，只有一份實(shí)例，用于進(jìn)行資源共享控制。
優(yōu)勢(shì)：使用簡(jiǎn)單，延時(shí)求值，易于跨模塊
敏捷原則：?jiǎn)我宦氊?zé)原則策略模式
應(yīng)用場(chǎng)景：定義算法族，封裝起來，使他們之間可以相互替換。
優(yōu)勢(shì)：使算法的變化獨(dú)立于使用算法的用戶
敏捷原則：接口隔離原則；多用組合，少用繼承；針對(duì)接口編程，而非實(shí)現(xiàn)。工廠模式
應(yīng)用場(chǎng)景：工廠方式創(chuàng)建類的實(shí)例，多與proxy模式配合，創(chuàng)建可替換代理類。
優(yōu)勢(shì)：易于替換，面向抽象編程，application只與抽象工廠和易變類的共性抽象類發(fā)生調(diào)用關(guān)系。
敏捷原則：DIP依賴倒置原則
六.單例會(huì)有什么弊端？
-
主要優(yōu)點(diǎn)：
- 1、提供了對(duì)唯一實(shí)例的受控訪問。
- 2、由于在系統(tǒng)內(nèi)存中只存在一個(gè)對(duì)象，因此可以節(jié)約系統(tǒng)資源，對(duì)于一些需要頻繁創(chuàng)建和銷毀的對(duì)象單例模式無疑可以提高系統(tǒng)的性能。
- 3、允許可變數(shù)目的實(shí)例。
-
主要缺點(diǎn)：
- 1、由于單利模式中沒有抽象層，因此單例類的擴(kuò)展有很大的困難。
- 2、單例類的職責(zé)過重，在一定程度上違背了“單一職責(zé)原則”。
- 3、濫用單例將帶來一些負(fù)面問題，如為了節(jié)省資源將數(shù)據(jù)庫連接池對(duì)象設(shè)計(jì)為的單例類，可能會(huì)導(dǎo)致共享連接池對(duì)象的程序過多而出現(xiàn)連接池溢出；如果實(shí)例化的對(duì)象長(zhǎng)時(shí)間不被利用，系統(tǒng)會(huì)認(rèn)為是垃圾而被回收，這將導(dǎo)致對(duì)象狀態(tài)的丟失。
