为什么 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
最佳答案
这可能是历史性的。 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)对象成为可能。
关于objective-c - 为什么 NSWindow 的 contentView 属性是类型 id?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9163716/