原作者：沒故事的卓同學(xué)
轉(zhuǎn)載自：http://www.reibang.com/p/604305a61e57
在原有的swift中的<code> private </code>其實(shí)并不是真正的私有洛姑，如果一個(gè)變量定義為private，在同一個(gè)文件中的其他類依然是可以訪問到的。這個(gè)場(chǎng)景在使用extension的時(shí)候很明顯。
class User {
private var name = "private"
}
extension User{
var accessPrivate: String {
return name
}
}
這樣帶來了兩個(gè)問題：
當(dāng)我們標(biāo)記為private時(shí)竖独，意為真的私有還是文件內(nèi)可共享呢？
當(dāng)我們?nèi)绻鈭D為真正的私有時(shí)挤牛，必須保證這個(gè)類或者結(jié)構(gòu)體在一個(gè)單獨(dú)的文件里预鬓。否則可能同文件里其他的代碼訪問到。
由此赊颠，在swift 3中，新增加了一個(gè)<code> fileprivate </code>來顯式的表明劈彪，這個(gè)元素的訪問權(quán)限為文件內(nèi)私有竣蹦。過去的private對(duì)應(yīng)現(xiàn)在的fileprivate。現(xiàn)在的private則是真正的私有沧奴，離開了這個(gè)類或者結(jié)構(gòu)體的作用域外面就無法訪問痘括。
open
open則是彌補(bǔ)public語義上的不足。
現(xiàn)在的pubic有兩層含義：
這個(gè)元素可以在其他作用域被訪問
這個(gè)元素可以在其他作用域被繼承或者override
繼承是一件危險(xiǎn)的事情。尤其對(duì)于一個(gè)framework或者module的設(shè)計(jì)者而言纲菌。在自身的module內(nèi)挠日，類或者屬性對(duì)于作者而言是清晰的，能否被繼承或者override都是可控的翰舌。但是對(duì)于使用它的人嚣潜，作者有時(shí)會(huì)希望傳達(dá)出這個(gè)類或者屬性不應(yīng)該被繼承或者修改。這個(gè)對(duì)應(yīng)的就是<code> final </code>椅贱。
<code> final </code>的問題在于在標(biāo)記之后懂算，在任何地方都不能override。而對(duì)于lib的設(shè)計(jì)者而言庇麦，希望得到的是在module內(nèi)可以被override计技，在被import到其他地方后其他用戶使用的時(shí)候不能被override。
這就是<code> open </code>產(chǎn)生的初衷山橄。通過open和public標(biāo)記區(qū)別一個(gè)元素在其他module中是只能被訪問還是可以被override垮媒。
下面是例子：
/// ModuleA:
// 這個(gè)類在ModuleA的范圍外是不能被繼承的，只能被訪問
public class NonSubclassableParentClass {
public func foo() {}
// 這是錯(cuò)誤的寫法航棱，因?yàn)閏lass已經(jīng)不能被繼承楔脯，
// 所以他的方法的訪問權(quán)限不能大于類的訪問權(quán)限
open func bar() {}
// final的含義保持不變
public final func baz() {}
}
// 在ModuleA的范圍外可以被繼承
open class SubclassableParentClass {
// 這個(gè)屬性在ModuleA的范圍外不能被override
public var size : Int
// 這個(gè)方法在ModuleA的范圍外不能被override
public func foo() {}
// 這個(gè)方法在任何地方都可以被override
open func bar() {}
///final的含義保持不變
public final func baz() {}
}
/// final的含義保持不變
public final class FinalClass { }
/// ModuleB:
import ModuleA
// 這個(gè)寫法是錯(cuò)誤的，編譯會(huì)失敗
// 因?yàn)镹onSubclassableParentClass類訪問權(quán)限標(biāo)記的是public癌蓖，只能被訪問不能被繼承
class SubclassA : NonSubclassableParentClass { }
// 這樣寫法可以通過髓帽，因?yàn)镾ubclassableParentClass訪問權(quán)限為 `open`.
class SubclassB : SubclassableParentClass {
// 這樣寫也會(huì)編譯失敗
// 因?yàn)檫@個(gè)方法在SubclassableParentClass 中的權(quán)限為public，不是`open'.
override func foo() { }
// 這個(gè)方法因?yàn)樵赟ubclassableParentClass中標(biāo)記為open驳阎，所以可以這樣寫
// 這里不需要再聲明為open抗愁，因?yàn)檫@個(gè)類是internal的
override func bar() { }
}
open class SubclassC : SubclassableParentClass {
// 這種寫法會(huì)編譯失敗，因?yàn)檫@個(gè)類已經(jīng)標(biāo)記為open
// 這個(gè)方法override是一個(gè)open的方法呵晚，則也需要表明訪問權(quán)限
override func bar() { }
}
open class SubclassD : SubclassableParentClass {
// 正確的寫法蜘腌，方法也需要標(biāo)記為open
open override func bar() { }
}
open class SubclassE : SubclassableParentClass {
// 也可以顯式的指出這個(gè)方法不能在被override
public final override func bar() { }
}
總結(jié)
現(xiàn)在的訪問權(quán)限則依次為：open，public饵隙，internal撮珠，fileprivate，private金矛。
有的人會(huì)覺得訪問權(quán)限選擇的增加加大了語言的復(fù)雜度芯急。但是如果我們思考swift語言的設(shè)計(jì)目標(biāo)之一就是一門安全的語言（“Designed for Safety”）就能理解這次的改動(dòng)。更加明確清晰的訪問權(quán)限控制可以使程序員表達(dá)出更準(zhǔn)確的意圖驶俊，當(dāng)然也迫使在編碼時(shí)思考的更加深入娶耍。
