在 Modern Runtime 中使用实例变量

Question

我在 Obj-c 和 Cocoa 方面有几年的经验，但现在才回到它以及 Obj-C 2.0 的进步等。

我正在尝试了解现代运行时和声明属性等。一让我有点困惑的是现代运行时能够隐式创建 iVar。 当然，这意味着在您的代码中您应该始终使用 self.property 来访问该值。

但是，在 init* 和 dealloc（假设您没有使用 GC）方法中，我们应该直接使用 iVar（在当前运行时）。

所以问题是：

1. 我们应该在 init* 中使用属性访问器并在 Modern Runtime 中使用 dealloc 吗？

2. 如果是这样，为什么会有所不同？ 难道只是因为编译器看不到 iVar？

3. 如果我需要重写访问器，我仍然可以访问将在运行时定义的 iVar，还是必须定义运行时将使用的实际 iVar？

4. 一次，如果我可以访问合成的 iVar，为什么我不能继续对 init* 和 dealloc 方法执行此操作？

我读了几次文档，但它们似乎对所有这些都有点模糊，我想确保我很好地理解它，以便决定我要如何继续编码。

希望我的问题很清楚。

---

测试快速总结：

1. 如果你没有在legacy中声明ivar，编译器会完全不高兴

2. < p>如果您在遗留编译器中的 ivar 周围使用 #ifndef __OBJC2__ 很高兴，您可以直接使用 ivar 并作为属性

3. 在现代运行时，您可以将 ivar 保留为未定义并作为属性访问

4. 在现代运行时，尝试直接访问 ivar 而不声明会在编译期间出错

5. @private当然，声明 ivar 允许直接访问 ivar，无论是旧版还是现代版

版现在并没有真正给出一个干净的前进方式，不是吗？

Answer 1

在当前（OS X 10.5/GCC 4.0.1）编译器中，您无法直接访问运行时合成的ivars。 OS X 运行时工程师之一 Greg Parker 指出 在 cocoa-dev 列表中这样（2009 年 3 月 12 日）：

在当前的编译器中不能。 A
未来的编译器应该修复这个问题。 使用
显式@private ivars在
与此同时。 @private ivar 不应该
被视为合同的一部分 -
这就是@private 的意思，强制执行
通过编译器警告和链接器
错误。

为什么没有办法
显式声明实例变量
在新运行时的 .m 文件中？

三个原因：（1）有一些
重要的设计细节
出，(2) 编译器工程师时间是
有限，并且 (3) @private ivars 是
总体来说已经足够好了。

因此，现在您必须使用点表示法来访问属性，即使在 init 和 dealloc 中也是如此。 这违背了在这些情况下直接使用 ivars 的最佳实践，但没有办法解决这个问题。 我发现在大多数情况下，使用运行时合成的 ivars 的便利性（以及性能优势）超过了这一点。 如果您确实需要直接访问 ivar，则可以按照 Greg Parker 的建议使用 @private ivar（没有什么可以阻止您混合显式声明的 ivar 和运行时合成的 ivar）。

更新 在 OS X 10.6 中，64 位运行时确实允许通过 self->ivar 直接访问合成的 ivars。

Answer 2

由于实例变量本身只能在现代运行时合成（并且必须在 32 位或 Leopard 之前的 @interface 中声明），因此声明 ivar 是最安全/最可移植的

• 我们应该在 init* 中使用属性访问器并通过 Modern Runtime 进行 dealloc 吗？

我的经验法则是，-init* 是“可能”，-dealloc 是“通常不会”。

初始化对象时，您需要确保正确复制/保留 ivars 的值。 除非属性的设置器有一些副作用使其不适合初始化，否则一定要重用属性提供的抽象。

释放对象时，您希望释放所有 ivar 对象，但不存储新对象。 执行此操作的一个简单方法是将属性设置为 nil (myObject.myIvar = nil)，这基本上会调用 [myObject setMyIvar:nil]。 由于传递给 nil 的消息会被忽略，因此不会有任何危险。 然而，当 [myIvar release] 时，这就有点矫枉过正了； 通常就是您所需要的。 一般来说，在释放行为与设置变量的行为不同的情况下，不要使用该属性（或直接使用 setter）。

我完全可以理解 eJames 反对在 init/dealloc 中使用属性访问器的论点，但另一方面是，如果您更改属性行为（例如，从保留更改为复制，或者只是分配而不保留）并且不使用它在 init 中，反之亦然，行为也可能不同步。 如果初始化和修改 ivar 的行为应该相同，请对两者使用属性访问器。

• 如果是这样，为什么会有所不同？ 难道只是因为编译器看不到ivar？

现代运行时更智能地处理类大小和布局，这就是为什么您可以更改 ivars 的布局而无需重新编译子类。 它还能够从相应属性的名称和类型推断出您想要的 ivar 的名称和类型。 Objective-C 2.0 运行时编程指南提供了更多信息，但同样，我不知道那里的细节解释得有多深入。

• 如果我需要重写访问器，我仍然可以访问将在运行时定义的 iVar，还是必须定义运行时将使用的实际 iVar？

我还没有对此进行测试，但我相信您可以在代码中访问命名的 ivar，因为它实际上必须创建。 我不确定编译器是否会抱怨，但我猜想，既然它会让你合成 ivar 而不会抱怨，它也足够聪明，可以了解合成的 ivar 并让你通过名称引用它。

• 再说一次，如果我可以访问合成的 iVar，为什么我不能继续对 init* 和 dealloc 方法执行此操作？

分配实例后，您应该能够随时访问该属性和/或 ivar。

Answer 3

还有另一个SO问题具有类似的信息，但它并不完全重复。

底线，来自 Objective-C 2.0 文档，并引用自 马克·贝西的回答如下：

依赖于运行时的行为存在差异（另请参阅“运行时差异”）：

对于旧版运行时，必须已在 @interface 块中声明实例变量。 如果存在与属性同名且类型兼容的实例变量，则使用该变量，否则会出现编译器错误。

对于现代运行时，实例变量是根据需要合成的。 如果同名的实例变量已经存在，则使用它。

我的理解如下：

您不应在 init* 和 dealloc 方法中使用属性访问器，其原因与您不应在遗留运行时中使用它们的原因相同：如果您稍后重写属性方法，并最终执行不应该在 init* 或 dealloc 中执行的操作，则会面临潜在的错误。

您应该能够合成 ivar 并覆盖属性方法，如下所示：

@interface SomeClass
{
}
@property (assign) int someProperty;
@end

@implementation SomeClass
@synthesize someProperty; // this will synthesize the ivar
- (int)someProperty { NSLog(@"getter"); return someProperty; }
- (void)setSomeProperty:(int)newValue
{
    NSLog(@"setter");
    someProperty = newValue;
}
@end

这让我认为您将能够在 init* 中访问合成的 ivar以及dealloc方法。 我能想到的唯一问题是 @synthesize 行可能必须出现在 init* 和 dealloc 的定义之前 源文件中的方法。

最后，由于在接口中声明的 ivars 仍然有效，所以这仍然是您最安全的选择。

Answer 4

我遇到了同样的问题。 我解决无法访问合成实例变量的方法如下：

public header

@interface MyObject:NSObject {
}
@property (retain) id instanceVar;
@property (retain) id customizedVar;
@end

private header /implementation

@interface MyObject()
@property (retain) id storedCustomizedVar;
@end

@implementation MyObject
@synthesize instanceVar, storedCustomizedVar;
@dynamic customizedVar;

- customizedVar {
  if(!self.storedCustomizedVar) {
    id newCustomizedVar;
    //... do something
    self.storedCustomizedVar= newCustomizedVar;
  }
  return self.storedCustomizedVar;
}

- (void) setCustomizedVar:aVar {
  self.storedCustomizedVar=aVar;
}

@end

它不是那么优雅，但至少它使我的公共头文件保持干净。

如果您使用 KVO，则需要将customizedVar 定义为storedCustomizedVar 的依赖键。

Answer 5

我对 Obj-C 比较陌生（但不是编程），并且也对这个主题感到困惑。

让我担心的方面是，似乎相对容易无意中使用 iVar 而不是属性。 例如写：

myProp = someObject;

而不是

self.myProp = someObject;

诚然，这是“用户”错误，但在某些代码中似乎仍然很容易意外执行，并且对于保留或原子属性，它可能会导致问题。

理想情况下，我希望能够让运行时在生成任何 iVar 时将某种模式应用于属性名称。 例如，始终使用“_”作为前缀。

目前在实践中，我正在手动执行此操作 - 显式声明我的 ivars，并故意为它们提供与属性不同的名称。 我使用旧式“m”前缀，因此如果我的属性是“myProp”，我的 iVar 将是“mMyProp”。 然后我使用 @synthesize myProp = mMyProp 将两者关联起来。

我承认这有点笨拙，而且需要额外输入一些内容，但对我来说，能够在代码中更清楚地消除歧义似乎是值得的。 当然，我仍然可能会出错并输入 mMyProp = someObject，但我希望“m”前缀能够提醒我注意我的错误。

如果我可以只声明属性并让编译器/运行时完成其余的事情，那感觉会好得多，但是当我有很多代码时，我的直觉告诉我，如果我仍然必须遵循手动规则，我会犯这样的错误用于初始化/释放。

当然，我也可能做错很多其他事情......