Swift 3：是否继承NSObject？ [英] Swift 3: subclassing NSObject or not?

问题描述

我已经阅读过一些帖子，例如这一篇，关于它们之间的区别在Swift中继承 NSObject ，或者只使用其原生基础 class 而不进行子类化。但它们都有点旧帖子，我不清楚这个话题。

I have read some posts like this one about the difference between subclassing NSObject in Swift or just having its native base class with no subclassing. But they all are a bit old posts, and I am not clear about this topic.

什么时候应该继承 NSObject ？子类化和非子类化之间的实际区别是什么？目前Swift中的推荐是什么？

When should you subclass NSObject? What is the actual difference between subclassing it and not subclassing? What is currently the recommendation in Swift?

推荐答案

Apple关于NSObject的文档说明以下内容：

NSObject是大多数Objective-C类层次结构的根类。通过NSObject，对象继承了运行时系统的基本接口以及表现为Objective-C对象的能力。

NSObject is the root class of most Objective-C class hierarchies. Through NSObject, objects inherit a basic interface to the runtime system and the ability to behave as Objective-C objects.

这表明，需要将NSObject子类化为代码中引入的类型，只要该类型的实例需要像Objective-C对象（或类本身，在某些更罕见的情况下）一样。

As this would suggest, you need to subclass NSObject for types introduced in your code whenever instances of that type need to behave like an Objective-C object (or the class itself, in some rarer cases).

我不知道超级明确的Apple提供了关于不何时继承NSObject的书面指导，超出建议减少动态调度或使用不依赖于子类化但是 protocol 扩展，即代码重用，通常是更静态的调度和价值类型友好）。我相信尽管大多数Swift程序员已经从Apple获得了提示，并且Swift语言功能作为避免在上述需求不存在的情况下引入基于NSObject的类型的标志。 也就是说，作为一般规则，当你真正需要Objective-C动态时，只引入基于NSObject的类型，最常见的是当你需要与Cocoa API接口时（特别是当你的代码与UI相关时：例如视图控制器，观点）。

I am not aware of super explicit Apple provided written guidance on when not to subclass NSObject, beyond suggesting reducing dynamic dispatch or presenting code reuse paradigms using that do not relying on subclassing but protocol extensions, i.e. code reuse that is generally more static dispatch and value type friendly). I believe it is fair to say though that most Swift programmers have taken hints from Apple, and Swift language features as signs to avoid introducing NSObject based types when the above-mentioned need is not there. That is, as a general rule, only introduce NSObject based types when you actually need the Objective-C dynamism, most commonly when you need to interface with Cocoa APIs (especially common when your code is UI related: e.g. view controllers, views).

正如答案所指出的那样问题链接到，使用Objective-C风格动态性能 objc_msgSend 的方法调度。虽然Swift类中的方法也是虚拟的，但是当您没有使用 @objc 属性明确标记方法时，编译器能够使用更快的方法调度方法 - 尤其是当切换整个模块优化，在Swift 3中更是如此< a href =https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md =noreferrer>类默认情况下不会打开用于超出定义类型的模块的子类。

As pointed out in an answer to the question you link to, with Objective-C style dynamism comes the performance of objc_msgSend based method dispatch. Although methods in Swift classes are also virtual, the compiler is able to use faster means of dispatching methods when you don't explicitly mark the methods with the @objc attribute – especially when Whole Module Optimization is toggled on, and even more so in Swift 3 where classes are not by default open for subclassing beyond the module that defines the type.

除了避免使用NSObject之外，您还可以完全避免使用基于类的引用类型案例写Swift时。例如，查看上面链接的值类型WWDC视频，或者例如此博客文章作为介绍。简而言之，使用值类型可以获得良好的局部推理，通常可以避免动态内存分配和引用计数开销（尽管不是普遍的，所以 - 引用类型的结构作为字段是警告）。

Beyond avoiding NSObject, you can also avoid class based reference types altogether in many cases when writing Swift. Take a look at for instance the value type WWDC videos linked above, or for example this blog post as an introduction. Briefly, using value types you gain good local reasoning, often avoid dynamic memory allocation and reference counting overhead (though not universally so – structs with reference types as fields being the caveat).

这篇关于Swift 3：是否继承NSObject？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！