我知道关于编码风格的讨论往往会以灾难和无尽的火焰战结束,但这不是我想达到的目标。在过去的十年中,我主要在Objective-C中看到了dealloc
方法的两种不同编码风格。第一个也是最常见的一个是将dealloc
放在文件的底部。这也是Apple在Xcode默认模板中使用的样式。这背后的逻辑似乎是当对象的结尾接近时调用dealloc
,所以文件的结尾似乎是一个很好的比喻。
另一方面,有几个人倾向于将dealloc
直接放在@synthesize
指令之下。在我看来,这有两个主要的缺点:
我认为的巨大优势是您可以在属性和相应的release
消息之间建立直接的可视连接。
另一件事是弄乱已经发布的变量。虽然我不认为这是必要的,特别是在dealloc
结束后整个变量被解构的对象上下文中,我倾向于也只是变量。我习惯于在函数范围内对变量执行此操作,因此我只是符合我的编码风格。
这就是我的大多数课程的样子:
@implementation Bar
@synthesize foo;
- (void)dealloc
{
[foo release], foo = nil;
[super dealloc];
}
// Initializers and other methods…
我已经提到了一些优点和缺点。对于这个话题你有什么看法?您在dealloc
和为什么中使用的编码样式是什么?还有其他优点和缺点我忘了提及吗?
我不想在这里开始一场火焰战争。我只是想知道你使用什么样的风格,如果你有特定的理由,或者这对你来说无关紧要。
答案 0 :(得分:16)
我想将dealloc
实现放在初始化器的正下方。这样,当我添加一个新的实例变量时,我记得在release
之后init
它。{/ p>
此外,我发现使用#pragma mark
指令使浏览文件更容易,这确实很有帮助。因此,我将init
和dealloc
方法“分组”在一个名为“初始化程序”的标题下。浏览文件时,使用这些标题可以更轻松地找到您要查找的内容而不会被dealloc
方法分心。
这可能是无聊的代码,但是人是重要的。
答案 1 :(得分:10)
如果没有特定的理由,请不要将你的ivar设置为nall。它没有任何意义,最多掩盖程序员错误,你最好找到而不是隐藏。
答案 2 :(得分:8)
我的订单:
@dynamic
指令(我在2011年的某个时候开始执行这些操作;之前,他们使用了访问器实现)+load
,+initialize
,+sharedFoo
,其他)dealloc
finalize
#pragma mark
指令)在dealloc
方法中:
nil
。该对象被部分解除分配;你为什么还要发信息? (如果你不是,那么没有什么可以看到ivars的价值。)nil
),请不要滥用逗号运算符。像[foo release], foo = nil
这样的表达式混合了类型(消息表达式中的第一个void
,然后是赋值表达式中的id
。这些是单独的陈述;把它们写成这样。[super dealloc]
永远是最后一个,并且总是在它上面有一个空行,强调它的存在。当然,我也打开了“将警告视为错误”,所以如果我忘记[super dealloc]
,我就会破坏我的构建。
答案 3 :(得分:5)
我将dealloc放在顶部,就在@synthesize指令下面。这是一个有点笨重,无聊的代码,但是非常重要的代码,所以它得到了最高的收费。此外,能够比较属性和释放是至关重要的。
答案 4 :(得分:3)
我把它放在底部。这允许我简单地点击结束并在我添加需要解除分配的内容时转到它。我也不希望它在我的属性合成器周围,因为这是欺骗。并非我所有的东西都必须附加一个合成访问器。哎呀,它甚至不一定都在初始化器中。如果我尝试以这种方式使用快捷方式,我可能会搞砸它。
答案 5 :(得分:-1)
- (id)init{
self = [super init];
if( self ) {
someVar = [[NSMutableArray alloc] init];
// something like the following shouldn't be released:
someString = [NSString stringWithFormat:@"ANumber: %d",10];
}
return self;
- (void)dealloc{
[someVar release]; someVar = nil;
[super dealloc];
}
这就是我这样做的方式:)