为什么我不应该在init/dealloc中使用Objective C 2.0访问器？

Question

在@ mmalc的 响应于这个问题,他指出:"一般来说,你应该不使用访问中的dealloc方法(或init)." 为什么mmalc这样说？

我能想到的唯一真正原因是性能和避免@dynamic制定者的未知副作用.

讨论？

Answer 1

它基本上是一个最小化错误可能性的指南.

在这种情况下,存在(可能性)您的setter/getter可能无意中对对象的状态做出直接或间接的假设.当对象处于设置或销毁之中时,这些假设可能是一个问题.

例如,在下面的代码中,观察者不知道'Example'正在被销毁,并且可以假设已经被释放的其他属性是有效的.

(你可以争辩说,你的对象应该在撕下自己之前删除所有观察者,这是一种很好的做法,另一个指导可以防止意外问题).

@implementation Example

-(void) setFoo:(Foo*)foo
{
   _foo = foo;
  [_observer onPropertyChange:self object:foo];
}

-(void) dealloc
{
   ...
   self.foo = nil;
}

@end

Answer 2

这完全是关于使用惯用的一致代码.如果您对所有代码进行了适当的模式化,那么有一些规则可以保证在init/dealloc中使用访问器是安全的.

最大的问题是(正如mmalc所说)设置属性默认状态的代码不应该通过访问器,因为它会导致各种令人讨厌的问题.问题是init没有理由设置属性的默认状态.出于多种原因,我一直在转向自我初始化的访问器,如下面的简单示例:

- (NSMutableDictionary *) myMutableDict {
    if (!myMutableDict) {
        myMutableDict = [[NSMutableDictionary alloc] init];
    }

    return myMutableDict;
}

这种属性初始化允许人们推迟许多实际上不必要的初始化代码.在上面的例子中,init不负责启动属性状态,并且在init方法中使用访问器是完全安全的(甚至是必要的).

不可否认,这确实对您的代码施加了额外的限制,例如,具有超类中属性的自定义访问器的子类必须调用超类访问器,但这些限制与Cocoa中常见的各种其他限制并不相符.

Answer 3

你是在自问自答:

1. 性能本身可能是一个非常充分的理由(特别是如果你的访问器是原子的).
2. 您应该避免访问者可能产生的任何副作用.

如果您的类可能是子类,则后者尤其是一个问题.

但是,目前尚不清楚为什么在Objective-C 2访问器中专门解决这个问题？无论您是自己使用声明属性还是编写访问器,相同的原则都适用.