在@mmalc'sresponse 到this question 中，他声明“一般情况下，您应该不在 dealloc（或 init）中使用访问器方法。”为什么mmalc会这样说？
我能想到的唯一真正原因是性能和避免@dynamic setter 的未知副作用。
讨论？
【问题讨论】：
标签： objective-c cocoa
它基本上是一个将错误可能性降至最低的指南。
在这种情况下，您的 setter/getter 可能会不经意间对对象的状态做出直接或间接的假设。当对象处于设置或销毁过程中时，这些假设可能会成为问题。
例如，在下面的代码中，观察者不知道“示例”正在被销毁，并且可以假设其他已被释放的属性是有效的。
（您可以争辩说您的对象应该在自行拆除之前移除所有观察者，这是一种很好的做法，也是防止意外问题的另一个准则）。
@implementation Example
-(void) setFoo:(Foo*)foo
{
_foo = foo;
[_observer onPropertyChange:self object:foo];
}
-(void) dealloc
{
...
self.foo = nil;
}
@end
【讨论】：
这就是使用惯用一致的代码。如果您正确地对所有代码进行模式化，则有一组规则可以保证在 init/dealloc 中使用访问器是安全的。
最大的问题是（正如 mmalc 所说）设置属性默认状态的代码不应通过访问器，因为它会导致各种令人讨厌的问题。问题是 init 没有理由设置属性的默认状态。出于多种原因，我一直在使用自初始化的访问器，如下面的简单示例：
- (NSMutableDictionary *) myMutableDict {
if (!myMutableDict) {
myMutableDict = [[NSMutableDictionary alloc] init];
}
return myMutableDict;
}
这种类型的属性初始化允许延迟许多实际上可能不需要的初始化代码。在上述情况下，init 不负责初始化属性状态，在 init 方法中使用访问器是完全安全的（甚至是必要的）。
诚然，这确实对您的代码施加了额外的限制，例如，对超类中的属性具有自定义访问器的子类必须调用超类访问器，但这些限制与 Cocoa 中常见的各种其他限制并没有冲突。
【讨论】：
nil 分配给此属性，因为访问器会自动创建一个数组的新实例。
object.x = foo 应该暗示紧接着object.x == foo 是YES。如果没有，也许（非属性）方法会更好。
您回答了自己的问题：
如果您的类可能是子类，则后者尤其是一个问题。
不过，不清楚为什么在 Objective-C 2 访问器中专门解决了这个问题？无论您是使用声明的属性还是自己编写访问器，都适用相同的原则。
【讨论】：
可能是 setter 具有应该运行的逻辑，或者可能是实现使用了一个名称与 getter/setter 不同的 ivar，或者可能是两个需要释放和/或将其值设置为 nil 的 ivar。唯一可靠的方法是调用 setter。 setter 有责任编写成在 init 或 dealloc 期间调用时不会发生不良副作用的方式。
来自“Cocoa 设计模式”，Buck，Yacktman，第 115 页：“...当您在现代 Objective-C 运行时或...中使用合成实例变量时，除了使用访问器之外，没有其他实用的替代方法...”
【讨论】：
事实上，对于一个频繁出现和消失的类（如细节视图控制器），您希望在 init 中使用访问器；否则，您最终可能会在 viewDidUnload 中释放一个您稍后尝试访问的值（它们在 CS193P 中显示...）
【讨论】：
您可以通过在分配/解除分配时不调用设置器来创建相同的问题。
我不认为直接在 init/dealloc 中使用 retain/release 可以实现任何目标。您只需更改可能的错误集。
每次您必须考虑财产分配/解除分配的顺序。
【讨论】：