作者：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。
