iOS 面向協(xié)議 Swift
在Swift語(yǔ)言開(kāi)始盛行的當(dāng)下逆皮，面向協(xié)議的開(kāi)發(fā)无畔，成為一個(gè)非常不錯(cuò)的思想啊楚，對(duì)整個(gè)工程架構(gòu)起到了很重要的作用，也讓開(kāi)發(fā)變得十分靈活浑彰。
那么恭理，什么是面向協(xié)議的開(kāi)發(fā)呢？以下幾個(gè)場(chǎng)景郭变，對(duì)于體會(huì)面向協(xié)議開(kāi)發(fā)有所幫助颜价。
- 首先我們有一個(gè)
動(dòng)物類，即父類诉濒，動(dòng)物按其棲息方式周伦，有水棲動(dòng)物如各種魚(yú)類，陸棲動(dòng)物如老虎大象未荒，還有兩棲動(dòng)物如河馬烏龜?shù)鹊茸ㄅ玻@些都是動(dòng)物類的子類。動(dòng)物可以奔跑、可以爬行寨腔，可以游泳速侈，但老虎大象可以游泳嗎？魚(yú)類可以爬行嗎迫卢？如果我們用代碼實(shí)現(xiàn)倚搬，每個(gè)子類都繼承動(dòng)物這個(gè)父類，如此靖避，繼承父類潭枣，就繼承了父類的一切比默！這是不是有些不太合理幻捏？- 依舊是
動(dòng)物類，我們知道鳥(niǎo)可以飛命咐，可飛這個(gè)動(dòng)作似乎飛機(jī)也能飛篡九，風(fēng)箏也能飛，無(wú)人機(jī)也能飛醋奠，足球也能飛榛臼，甚至熱氣球也能飛，鋼鐵俠也能飛窜司，難道我們都要繼承自動(dòng)物嗎沛善？這合理嗎？- 一個(gè)系列的車塞祈，有的有導(dǎo)航系統(tǒng)金刁，有的沒(méi)有導(dǎo)航系統(tǒng)，當(dāng)某一天沒(méi)有導(dǎo)航系統(tǒng)的需要加裝導(dǎo)航系統(tǒng)议薪，難道是要重新拆了按照有導(dǎo)航系統(tǒng)的車的結(jié)構(gòu)重新制造嗎尤蛮？這合理嗎？
- 具體到工程代碼斯议，展示在用戶面前的內(nèi)容产捞，有些需要用戶登錄才能操作，比如有10個(gè)界面需要用戶登錄哼御，難道我們要在這10個(gè)界面創(chuàng)建用戶登錄界面或者編寫(xiě)登錄功能嗎坯临？這合理嗎？
顯而易見(jiàn)恋昼，上面四種場(chǎng)景是不合理的尿扯，那么面向協(xié)議的開(kāi)發(fā)，就顯得尤為重要：
對(duì)于第1焰雕、2個(gè)場(chǎng)景衷笋，我們可以定義這樣一個(gè)協(xié)議，里面包含了動(dòng)物的各種行為協(xié)議，哪一類動(dòng)物就繼承哪一種協(xié)議：
protocol Runable {
var age: Double { set get}
var headerCount: Int { get }
}
extension Runable {
var age: Double {
return 10
}
var headerCount: Int {
return 1
}
func running() {
print("running")
}
}
protocol Swimable {
}
extension Swimable {
func swimming() {
print("swimming")
}
}
protocol flyable {
}
extension flyable {
func flying() {
print("flying")
}
}
在Swift中辟宗，實(shí)現(xiàn)協(xié)議可以不遵守基協(xié)議爵赵，也可以在extention中為協(xié)議函數(shù)添加默認(rèn)實(shí)現(xiàn)，當(dāng)然也可以定義屬性泊脐，不過(guò)定義屬性的話空幻，要指定是可讀可寫(xiě)，還是只讀屬性容客，一樣的可以在extension中添加默認(rèn)實(shí)現(xiàn)秕铛。
當(dāng)然，一般情況下缩挑，屬性一般寫(xiě)在父類中但两！這樣的話，不管是哪一種動(dòng)物或者飛機(jī)什么的只要遵守對(duì)應(yīng)的協(xié)議供置，就可以重新實(shí)現(xiàn)協(xié)議谨湘，場(chǎng)景中的不合理問(wèn)題也迎刃而解。
既然協(xié)議可以添加默認(rèn)實(shí)現(xiàn)芥丧，那是否可以在協(xié)議中封裝一個(gè)小功能呢紧阔？比如車載系統(tǒng)功能，工程中的登錄功能续担，當(dāng)需要用的時(shí)候擅耽，遵守協(xié)議，直接拿來(lái)用就是了物遇。
答案自然是可以的:
@objc protocol LoginProtocol {
@objc optional func login(inView view: UIView)
}
extension SportProtocol {
func login(inView view: UIView) {
let loginView = TCLoginView()
view.addSubview(loginView)
}
}
由上可以看出乖仇，協(xié)議，就像是一個(gè)功能小組件一樣挎挖，把相同的功能拆分出來(lái)这敬，不僅讓我們減少了代碼的冗余，而且十分方便蕉朵，哪兒需要崔涂，哪兒遵守，哪兒實(shí)現(xiàn)始衅！
最后冷蚂，如果是某個(gè)類的協(xié)議，需要用的協(xié)議屬性汛闸，那么就需要協(xié)議遵守基協(xié)議NSObjectProtocol蝙茶，或者class，如非必要诸老，一般我選擇更加輕量級(jí)的后者隆夯！
@objc protocol TCShowViewDelegate: class {
@objc optional func showView(_ view: TCShowView, didSelectedBtn btn: UIButton)
}
// view中
weak var delegate: TCShowViewDelegate?
