Swift 3必看：新的访问控制fileprivate和open - 简书
Swift 3必看：新的访问控制fileprivate和open
在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则是弥补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”）就能理解这次的改动。更加明确清晰的访问权限控制可以使程序员表达出更准确的意图，当然也迫使在编码时思考的更加深入。
欢迎关注我的微博：相关链接：
iOS民间程序员。运营靠偷，进攻靠莽。Swift 方法和属性应该被尽量声明成 private 么? - 知乎6被浏览1909分享邀请回答0添加评论分享收藏感谢收起与世界分享知识、经验和见解Swift 3必看：新的访问控制fileprivate和open
招聘信息：
在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则是真正的私有，离开了这个类或者结构体的作用域外面就无法访问。openopen则是弥补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”）就能理解这次的改动。更加明确清晰的访问权限控制可以使程序员表达出更准确的意图，当然也迫使在编码时思考的更加深入。欢迎关注我的微博：相关链接：文章转自
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量11857点击量6086点击量4522点击量3786点击量3183点击量2969点击量2927点击量2759点击量2360
&2016 Chukong Technologies,Inc.
京公网安备89中国领先的IT技术网站
51CTO旗下网站
Swift扩展的三个微妙细节
每当我初次翻看某文档时，我都走马观花似的快速阅过，还一边点着头一边喃喃自语说：“好！懂了，就这么回事！”，可是过后当我真正要运用到这些我以为已经理解了的知识点时，却发现实际情况和我想的往往不一样，每当这时我就懵了，心想：“哇哦…怎么回事？这和我想的完全不一样啊！文档里有说这事吗？”。
作者：来源：开发技术前线| 09:50
每当我初次翻看某文档时，我都走马观花似的快速阅过，还一边点着头一边喃喃自语说：&好！懂了，就这么回事！&，可是过后当我真正要运用到这些我以为已经理解了的知识点时，却发现实际情况和我想的往往不一样，每当这时我就懵了，心想：&哇哦&怎么回事？这和我想的完全不一样啊！文档里有说这事吗？&。
最近的几次讨论促使我扪心自问是否真正的理解了Swift中的扩展。我阅读过关于扩展的文档，并且我&认为&我自己对这块内容已经是理解的相当透彻了。可是这几次讨论，加上自己私下通过敲代码的验证，让我发现了我原先不曾注意到几个微妙的细节。
更新：这篇文章刚一发表，Swift社区就出手襄助并帮助我弄明白了我最根本的纠结点在哪。为此，我写了另一篇文章&阐明Swift访问控制&进一步说明我之前的误解。为了避免犯我曾今犯过的错误，我建议大家去读一读。
三个关于扩展的微妙细节
对下面列出的三个细节的思考严重挑战了我之前对Swift扩展的理解：
Swift扩展对它所扩展类型的visibility。比如，扩展能访问被private所修饰的内容吗?
定义扩展的位置是否对扩展的visibility有影响。比如我这有一个类型我想写个扩展，把扩展写在同一个源文件里和把扩展写在另一个文件里有什么区别吗？
扩展里&成员&的默认访问修饰符以及是否给他们添加修饰对这个扩展作为一个类型的公共接口的影响。
在我开始之前，假设我有一个公共结构体Person。这个结构体有一些私有属性，name，gender，和age。用一个枚举把Gender封装了一下。这个结构体看起来如下：
public&struct&Person&{&&&&&private&var&name:&String&&&&&private&var&gender:&Gender&&&&&private&var&age:&Int&&&&&&&&public&init(name:&String,&gender:&Gender,&age:&Int)&{&&&&&&&&&self.name&=&name&&&&&&&&&self.gender&=&gender&&&&&&&&&self.age&=&age&&&&&}&&&&&&&&public&func&howOldArdYou()&-&&String&{&&&&&&&&&return&formattedAge()&&&&&}&&&&&&&&&&&&&private&func&formattedAge()&-&&String&{&&&&&&&&&switch&self.gender&{&&&&&&&&&case&.Male:&&&&&&&&&&&&&return&&I'm&\(self.age).&&&&&&&&&&case&.Female:&&&&&&&&&&&&&return&&Not&telling.&&&&&&&&&&}&&&&&}&&&&&&&&public&enum&Gender&{&&&&&&&&&case&Male&&&&&&&&&case&Female&&&&&}&}&
现在，就让我们给Person写个扩展，通过实践来弄清楚刚刚提到的三个小细节&
扩展对类型的访问能力
当我提出第一个细节时，关于扩展对被扩展类型的访问能力时，我问了一个问题：&扩展能访问到被private修饰的内容吗?&。答案一开始出乎我的预料：能&扩展能访问到。
然而，这里就要考虑到第二个细节所涉及的问题，那就是：在哪里定义这个扩展是绝对有影响的。
定义在同一个文件里
如果扩展和类型是在写同一个源文件里，则扩展能访问到在类型中被priavte所修饰的内容。
举个栗子，在Person.swift里定义一个Person的扩展就会允许这个扩展访问被private修饰的变量和方法
extension&Person&{&&&&&func&getAge()&-&&Int&{&&&&&&&&&return&age&&&&&&}&&&&&&&&func&getFormattedAge()&-&&String&{&&&&&&&&&return&formattedAge()&&&&&&}&}&
至于为什么把扩展写在同一个源文件里头会这样，我自己的推理是其实可以在写类型的时候，就把扩展的implementation当作类型的一部分给写了，这样的最终效果是一样的。&这谁知道？！什么？？为啥？&，我当时就没想明白&
我在我要&扩展&的类型的源文件里，所以无论是我把要新添加的功能当作这个类型的扩展写下来，或是就在这个类型里面定义我原本打算写在扩展里的功能是没有区别的，都是一样的效果。
所以，站在编译器的角度来看，编译器可能会说：&好吧，我看到这里写了一个扩展，但是真没这个必要，因为扩展和类型都在同一个源文件里&，所以开发者完全可以把扩展里的这些代码直接写在类型里面&，所以他／她能够访问到被private修饰的代码段。&
更新:我上面的写的推理恰恰说明了我压根就没搞明白Swift访问控制机制。所以我建议大家读一读我后来写的&阐明Swfit控制机制&这篇文章，里面有更多的细节。
定义在不同文件里
把扩展写在另一个文件里，则扩展无法访问类型中那些被private修饰的内容了。
按照上文我自己推理的逻辑来反过来想，定义在不同文件中就访问不了私有属性对我来说也是说的通的。
大多数情况下，你都会给那些你没有源代码的类型扩展，在这种情况下，扩展就只能访问那些被public修饰的内容了。
默认情况下的扩展访问控制
对最后一个细节的验证也让我更深的体会。苹果官方文档说了，但是直到我动手验证了一番，我才算领会到了默认访问控制修饰符给扩展所造成的微妙的影响。
没有明确声明访问修饰赋时的默认访问
简单的说，当你声明一个扩展但没有特别明确指明访问修饰符时（默认情况下），这个扩展的默认访问等级取决于被扩展的那个类型的访问等级。
* 如果类型是public或者是internal，那么扩展的implementation的&成员&就默认为internal。这里让我没想到是，除非你特别声明，那么给public类型的扩展的成员变量在默认情况下也是internal。
* 如果类型是private，那么默认情况下扩展的implementation中的&成员&也是private
下面就是在我们不明确的声明添加什么访问修饰的前提下，来看扩展会是一个什么反应（为了能访问私有属性变量和方法，我在Person.swift里定义了这个扩展）：
public&struct&Person&{&&&&&&&&&&&&&&}&&&&extension&Person&{&&&&&func&getAge()&-&&Int&{&&&&&&&&&return&age&&&&&}&&&&&&&&func&getFormattedAge()&-&&String&{&&&&&&&&&return&formattedAge()&&&&&}&}&
同一模块像上面这段代码用默认的访问修饰符时就会允许在同一个模块中的实例访问扩展里的API。但是，如果被扩展的类型的实例是在另一个模块（比如在测试模块）,则无法访问扩展中任何新增的公共API。
不同模块（测试）
因为某些原因，我一直都以为如果给一个是public的类型添加扩展，那么扩展里的成员也理应是public。我不知道为什么我会这么想，但是幸好我的验证把这点捋清楚了。
正常声明扩展，但给扩展的implementation添加public修饰
给扩展的implementation的成员添加了public访问控制修饰，那么不管是在同一模块还是不同模块（test target）都能访问这些成员。
只要成员被public修饰，那么在同一个源文件里声明扩展还是在另一个文件里声明扩展已经无所谓了&但是，正如前文所讲，只有在同一个源文件中声明的扩展才能够访问那些被private修饰的类型成员变量。
在不同（左）和同一个（右）源文件中声明的扩展
在不同模块中也能访问公共的扩展成员变量
这里请注意，在我写extension Person {...}时，我没有给这个扩展添加任何的修饰，我只是给这个扩展的成员添加了public。即便如此，新添加的方法仍然可以在不同的模块中被访问到。
也就是说，没有必要写public extension Person {...}。因为Person已经是public了，所以基于Person的扩展也就很自然的延用了类型本身的访问等级。
对我来说，这篇文章所提到的三个关于Swift扩展的细节已足以让我敲敲代码去验证一番了。我希望这里所作的分析能够为那些尝试理解Swfit扩展的朋友扫清一些障碍。
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条外电头条原创原创
24H热文一周话题本月最赞
讲师：5人学习过
讲师：29人学习过
讲师：5人学习过
精选博文论坛热帖下载排行
本书系统地介绍了在Linux平台下用C语言进行程序开发的过程，通过列举大量的程序实例，使读者很快掌握在Linux平台下进行C程序开发的方法和技...
订阅51CTO邮刊