在swift 3中新增加了兩種訪問控制權限 fileprivate和 open。下面將對這兩種新增訪問控制做詳細介紹。

fileprivate

在原有的swift中的 private其實並不是真正的私有，如果一個變數定義為private，在同一個檔案中的其他類依然是可以訪問到的。這個場景在使用extension的時候很明顯。

class User {
    private var name = "private"
}

extension User{
    var accessPrivate: String {
        return name
    }
}

這樣帶來了兩個問題：

• 當我們標記為private時，意為真的私有還是檔案內可共享呢？
• 當我們如果意圖為真正的私有時，必須保證這個類或者結構體在一個單獨的檔案裡。否則可能同文件裡其他的程式碼訪問到。

由此，在swift 3中，新增加了一個 fileprivate來顯式的表明，這個元素的訪問許可權為檔案內私有。過去的private對應現在的fileprivate。現在的private則是真正的私有，離開了這個類或者結構體的作用域外面就無法訪問。

open

open則是彌補public語義上的不足。
現在的pubic有兩層含義：

• 這個元素可以在其他作用域被訪問
• 這個元素可以在其他作用域被繼承或者override

繼承是一件危險的事情。尤其對於一個framework或者module的設計者而言。在自身的module內，類或者屬性對於作者而言是清晰的，能否被繼承或者override都是可控的。但是對於使用它的人，作者有時會希望傳達出這個類或者屬性不應該被繼承或者修改。這個對應的就是 final

final的問題在於在標記之後，在任何地方都不能override。而對於lib的設計者而言，希望得到的是在module內可以被override，在被import到其他地方後其他使用者使用的時候不能被override。

這就是 open產生的初衷。通過open和public標記區別一個元素在其他module中是隻能被訪問還是可以被override。

下面是例子：

/// ModuleA:

// 這個類在ModuleA的範圍外是不能被繼承的，只能被訪問
public class NonSubclassableParentClass {

    public func foo() {}

    // 這是錯誤的寫法，因為class已經不能被繼承，
    // 所以他的方法的訪問許可權不能大於類的訪問許可權
    open func bar() {}

    // final的含義保持不變
    public final func baz() {}
}

// 在ModuleA的範圍外可以被繼承
open class SubclassableParentClass {
    // 這個屬性在ModuleA的範圍外不能被override
    public var size : Int

    // 這個方法在ModuleA的範圍外不能被override
    public func foo() {}

    // 這個方法在任何地方都可以被override
    open func bar() {}

    ///final的含義保持不變
    public final func baz() {}
}

/// final的含義保持不變
public final class FinalClass { }
 

/// ModuleB:

import ModuleA

// 這個寫法是錯誤的，編譯會失敗
// 因為NonSubclassableParentClass類訪問許可權標記的是public，只能被訪問不能被繼承
class SubclassA : NonSubclassableParentClass { }

// 這樣寫法可以通過，因為SubclassableParentClass訪問許可權為 `open`.
class SubclassB : SubclassableParentClass {

    // 這樣寫也會編譯失敗
    // 因為這個方法在SubclassableParentClass 中的許可權為public，不是`open'.
    override func foo() { }

    // 這個方法因為在SubclassableParentClass中標記為open，所以可以這樣寫
    // 這裡不需要再宣告為open，因為這個類是internal的
    override func bar() { }
}

open class SubclassC : SubclassableParentClass {
    // 這種寫法會編譯失敗，因為這個類已經標記為open
    // 這個方法override是一個open的方法，則也需要表明訪問許可權
    override func bar() { } 
}

open class SubclassD : SubclassableParentClass {
    // 正確的寫法，方法也需要標記為open
    open override func bar() { }    
}

open class SubclassE : SubclassableParentClass {
    // 也可以顯式的指出這個方法不能在被override
    public final override func bar() { }    
}

總結

現在的訪問許可權則依次為：open，public，internal，fileprivate，private。
有的人會覺得訪問許可權選擇的增加加大了語言的複雜度。但是如果我們思考swift語言的設計目標之一就是一門安全的語言（“Designed for Safety”）就能理解這次的改動。更加明確清晰的訪問許可權控制可以使程式設計師表達出更準確的意圖，當然也迫使在編碼時思考的更加深入。