diff --git a/source/SUMMARY.md b/source/SUMMARY.md index cd3cdcb8..eb54a93f 100755 --- a/source/SUMMARY.md +++ b/source/SUMMARY.md @@ -45,4 +45,5 @@ * [造个类型不是梦-白话Swift类型创建](chapter4/02_Type_Custom.md) * [WWDC里面的那个“大炮打气球”](chapter4/03_Ballons.md) * [Swift与C语言指针友好合作](chapter4/04_Interacting_with_C_Pointers.md) - * [引用类型和值类型的恩怨](chapter4/05_Value_and_Reference_Types.md) \ No newline at end of file + * [引用类型和值类型的恩怨](chapter4/05_Value_and_Reference_Types.md) + * [访问控制和protected](chapter4/06_access_control_&_protected.md) \ No newline at end of file diff --git a/source/chapter1/03_revision_history.md b/source/chapter1/03_revision_history.md index cb50cde4..52013eac 100644 --- a/source/chapter1/03_revision_history.md +++ b/source/chapter1/03_revision_history.md @@ -32,19 +32,19 @@ 2014-08-18 @@ -91,16 +91,16 @@ 重写了继承(Inheritance) 这一章:删除了本章中关于构造器重写的介绍性报道;转而将更多的注意力放到新增的部分——子类的新功能,以及如何通过重写(overrides)修改已有的功能。另外,小节 重写属性的Getters和Setters(Overriding Property Getters and Setters) 中的例子已经被替换为展示如何重写一个 description 属性. (而关于如何在子类的构造器中修改继承属性的默认值的例子,已经被移到 构造过程(Initialization) 这一章.)
  • - 更新了 构造器的继承与重写(Initializer Inheritance and Overriding) 小节以标示: 重写一个特定的构造器必须使用 override 修改器. + 更新了 构造器的继承与重写(Initializer Inheritance and Overriding) 小节以标示: 重写一个特定的构造器必须使用 override 修饰符.

  • - 更新 Required构造器(Required Initializers) 小节以标示:required 修改器现在需要出现在所有子类的required构造器的声明中, 而required构造器的实现,现在可以仅从父类自动继承。 + 更新 Required构造器(Required Initializers) 小节以标示:required 修饰符现在需要出现在所有子类的required构造器的声明中, 而required构造器的实现,现在可以仅从父类自动继承。

  • 中置(Infix)的 运算符函数(Operator Functions) 不再需要@infix 属性.

  • - 前置和后置运算符(Prefix and Postfix Operators)@prefix@postfix 属性,已变更为 prefixpostfix 声明修改器(declaration modifiers). + 前置和后置运算符(Prefix and Postfix Operators)@prefix@postfix 属性,已变更为 prefixpostfix 声明修饰符(declaration modifiers).

  • 增加一条注解:当Prefix和postfix运算符被作用于同一个操作数时,关于前置和后置运算符(Prefix and Postfix Operators)的顺序(postfix运算符会先被执行) @@ -109,10 +109,10 @@ 在运算符函数(Operator functions)中, 组合赋值运算符(Compound Assignment Operators) 不再使用 @assignment 属性来定义函数.

  • - 在这个版本中,在定义自定义操作符(Custom Operators) 时,修改器(Modifiers)的出现顺序发生变化。比如, 现在,你该编写 prefix operator, 而不是 operator prefix. + 在这个版本中,在定义自定义操作符(Custom Operators) 时,修饰符(Modifiers)的出现顺序发生变化。比如, 现在,你该编写 prefix operator, 而不是 operator prefix.

  • - 增加信息:关于dynamic 声明修改器(declaration modifier),于章节 声明修改器(Declaration Modifiers). + 增加信息:关于dynamic 声明修饰符(declaration modifier),于章节 声明修饰符(Declaration Modifiers).

  • 增加信息:字面量Literals 的类型推导(type inference) @@ -168,7 +168,7 @@ 更新章节 类型标注(Type Annotations) :多个相关变量可以用“类型标注”(type annotaion)在同一行中声明为同一类型。

  • - @optional, @lazy, @final, @required 等关键字被更新为 optional, lazy, final, required 参见声明修改器(Declaration Modifiers). + @optional, @lazy, @final, @required 等关键字被更新为 optional, lazy, final, required 参见声明修饰符(Declaration Modifiers).

  • 更新整本书 —— 引用 ..< 作为区间运算符(Half-Open Range Operator) (取代原先的.. ). diff --git a/source/chapter4/05_Value_and_Reference_Types.md b/source/chapter4/05_Value_and_Reference_Types.md index 9508316a..049a8374 100644 --- a/source/chapter4/05_Value_and_Reference_Types.md +++ b/source/chapter4/05_Value_and_Reference_Types.md @@ -9,9 +9,7 @@ - [值类型与引用类型的区别](#difference-two) - [Mutation(修改)在安全中扮演的角色](#act-in=mutation) - [如何选择类型](#how-to-choose) -- [支持Bool类型判断](#condition-by-bool) -- [支持兼容各们各派的类型](#support-all-type) -- [完善OCBool的布尔基因体系](#make-up-type) + ### Swift里面的类型分为两种: diff --git a/source/chapter4/06_access_control_&_protected.md b/source/chapter4/06_access_control_&_protected.md new file mode 100644 index 00000000..f03e47ac --- /dev/null +++ b/source/chapter4/06_access_control_&_protected.md @@ -0,0 +1,41 @@ +> 翻译:[老码团队翻译组-Arya](http://weibo.com/littlekok/) +> 校对:[老码团队翻译组-Jame](http://weibo.com/u/5241713117) + +# 访问控制和protected +----------------- + + +原文再续,书折第一回。 + +很多其他编程语言都有一种”protected“设定,可以限制某些类方法只能被它的子类所使用。 + +Swift支持了访问控制后,大家给我们的反馈都很不错。而有的开发者问我们:“为什么Swift没有类似protected的选项?” + + + +**当我们在设计Swift访问控制的不同等级时,我们认为有两种主要场景:** + +* 在一个APP里:隐藏某个类的私密细节。 +* 在一个开源框架里:不让导入这个框架的APP,随便接触框架的内部实现细节。 + +上面的两种常见情况,对应着private和internal这两个等级。 + +而protected相当于把访问控制和继承特性混在一起,把访问控制的等级设定增加了一个维度,使之复杂化。即使设定了protected,子类还是可以通过新的公开方法、新的属性来接触到所谓“protected”了的API。另一方面,我们可以在各种地方重写一个方法,所谓的保护却没有提供优化机制。这种设定往往在做不必要的限制 一 protected允许了子类,但又禁止所有其他别的类(包括那些帮助子类实现某些功能的类)接触父类的成员。 + +有的开发者指出,apple的框架有时候也会把给子类用的API分隔出来。这时候protected不就有用了吗?我们研究后发现,这些方法一般属于下面两种情况:一是这些方法对子类以外的类没啥用,所以不需要严格保护(例如上面说的协助实现某些功能的类)。二是这些方法就是设计出来被重写,而不是直接用的。举个例子,`drawRect(_:) `就是在UIKit基础上使用的方法,但它不能在UIKit以外应用。 + +除此之外,如果有了protected,它要怎么样和extension相互作用呢?一个类的extension能接触它的protected成员吗?一个子类的extension可以接触父类的protected成员吗?extension声明的位置对访问控制等级有没有影响呢?(复杂到要哭了是不是?) + +对访问控制的设计,也依循了Objective-C开发者(包括apple内外的)的常规做法。Objective-C方法和属性一般在.h头文件里声明,但也可以写在.m实现文件里。假如有一个公开的类,想把里面某些部分设为只有框架内可以获取时,开发者一般会创建另一个头文件给内部使用。以上三种访问级别,就对应了Swift里面的public,private和internal。 + +Swift的访问控制等级和继承无关,是单维度、非常清楚明了的。我们认为这样的模式更简洁,同时满足了最主要的需求:将一个类、或一个框架的实现细节隔离保护起来。这可能和你以前用过的不同,但我们鼓励你试试看。 + +----------------- +本章节不是老码的原创,老码认真的阅读了苹果的官方博客,且自己的练习总结,如果小伙伴们费了吃奶的劲还是看不懂,请找度娘谷歌,还是看不懂请到老码[官方微博](http://weibo.com/u/5241713117)咆哮。 + +##### 本文由翻译自Apple Swift Blog :[access control & protected](原文地址:https://developer.apple.com/swift/blog/) + + + + +