Hi,SwiftGG 翻译组启用了新的域名:swiftgg.team今后翻译组的各项活动将会在新域名下开展,不要错过哦!

作者:Erica Sadun,原文链接,原文日期:2015-12-18
译者:JackAlan;校对:靛青K;定稿:shanks

你上一次在 Swift 中继承一个类是什么时候?而且这个类是你创建的但不是 Cocoa 体系中的一部分。在 protocol 扩展和一般的 extension 扩展存在的情况下,你多久继承一次非 Cocoa 类型的 class ?

如果你的答案在 0% 和 5% 之间,那你是相当具有代表性的。在 Swift 的类型体系中,引用类型不再使用继承来紧密耦合了。

进一步来说,问你多久创建一次类和子类的目的是:他们将来会被继承,通过一个特定模块之外的 API 客户端。(假设,当然,你不是 Apple,并且你没有在写 view 和 controller)。

当继承成为例外而不是规则,是时候考虑默认创建 final 类?或者将模块封装为 internal-by-default 更好?这样公开类在原模块外就不能被继承。

辩论目前如火如荼的展开在 Swift 进化列表中,关于这如何进行,以及是否应该这么做,是否类应该被设计为强制调用父类以重写方法(需要上层调用)。

John McCall 写道:


我们目前的意图是,公开的继承和重写将被锁定为默认,但是内部的继承和重写不会。我认为这达到了平衡,此外,这与一般语言的代码演进是一致的,通过以下几种方式将促进 “无副作用” 迅速发展:

(1) 避免手工管理的障碍,当你正在 hack 一个模块最初的实现代码,但是
(2) 不会让最初的实现代码在内部隐源,并且二进制兼容允许模块之外的代码,以及
(3) 提供良好的语言工具,来逐渐的把那些最初的原型接口构建为更强的内部抽象。

所有默认行为的硬限制都维系在模块边界上,因为我们假定,当你之前犯了一个错误的决定,这能直接的在模块内部修复任何问题。

所以,okay,默认一个类是可继承的,并且不是真的这样设计的,现在模块中有一些子类,这导致了一些问题。只要没人改变缺省情况 (他们本可以无所顾忌的在任何情况下做,但如果只需要一个外部的子类,那就不太可能去做),所有这些子类仍是模块内的,你仍然有自由的控制权,以纠正最初的错误设计。


Joe Groff 的想法:


强大的子类化能力要求有意识的设计,就像 API 设计的其他所有方面一样。


Jordan Rose:


关于此有趣的事情是,遗漏的错误:没有考虑是否一个类应该是 final ,这比另一种选择更糟糕。这里忽略一下优化,一个开始是 final 的类,之后就无法更改;这无法改变这个类目前是如何使用的,对于许多库发展问题,这是最好的答案: 缺省情况应该是安全的,类的设计者可以选择以后再改进。


本文由 SwiftGG 翻译组翻译,已经获得作者翻译授权,最新文章请访问 http://swift.gg

文章目录