objective-c - 为什么 NSWindow 的 contentView 属性是类型 id？

Question

为什么 NSWindow 类的 contentView 属性是 id 而不是 NSView

这对我来说没有意义，为什么 contentView 不是 NSView 子类。

所以在我的例子中，我必须像这样输入它才能访问它的框架:

NSView *contentView = self.window.contentView; // returns an `id`
CGRect frame = contentView.frame

取而代之的是编译器不喜欢的:

CGRect frame =  self.window.contentView.frame; // This does not compile

Answer 1

这可能是历史性的。 Objective-C 支持严格类型，但它也支持“鸭子类型”，您不关心对象是什么类，您只关心它响应什么消息(也就是说，如果它看起来像鸭子并且叫起来像鸭子，那么它很可能是鸭子)。您可以将每个对象指针键入为 id 并发送任何消息。事实上，接收方不需要为它接收到的任何消息实现方法:它也可以将消息转发给另一个对象。

在 Application Kit(OpenStep 和 Cocoa 的前身 GUI 框架)中，几乎所有对象都是通过鸭子类型使用的。这是来自 Application Kit 3.2 版的 Window 的(部分)界面。

@interface Window : Responder
{
  NXRect frame;
  id contentView;
  id delegate;
  id firstResponder;
  id lastLeftHit;
  id lastRightHit;
  id counterpart;
  id fieldEditor;
  int winEventMask;
  int windowNum;
  float backgroundGray;
  //some bit masks indicating whether the window is visible, is key etc.
}
-contentView;
-setContentView:aView;
//more methods
@end

请注意，contentView ivar 被定义为 id，并且访问器方法中的所有类型都被隐式定义为 id 也是(所以 -setContentView: 返回一个对象:可能是 Window 实例 self)。这就是 1990 年代早期大多数 Objective-C 代码的样子:Application Kit 可能 是 1990 年代早期大多数 Objective-C 代码。

NSWindow 是在 AppKit 的第一个版本中引入的 - 1994 年成为 Cocoa 的 GUI 框架。AppKit 通常使用比 Application Kit 更严格的类型声明，但并没有严格遵守。事实上，AppKit 的 NSWindow 甚至可能包含来自 Application Kit 的 Window 的代码，并且此 contentView ivar 未在更改中更新。

确实，Objective-C 变量中对类型一致性的严格要求是最近才出现的。大多数严格性是通过属性声明(除了 C 存在并支持强制转换之外是强类型的)或通过更改允许可选方法的协议(protocol)引入的，从而使严格类型化委托(delegate)对象成为可能。