省略属性的 ivars 声明是否会导致麻烦或泄漏？

Question

我开始针对iOS4进行学习和开发，所以我只是跳过了旧的ivar声明约定，开始使用纯属性，甚至没有声明ivars。一切都很顺利，我什至在应用商店发布了我的第一个自制应用程序。但后来在我的开发公司，人们告诉我他们仍在使用旧的约定，并使用下划线名称声明 ivars，使用属性并合成它们（请参阅最后的示例）。他们还表示，仅当需要外部访问 ivars 时才使用属性，而对于内部访问，他们使用直接 ivars（用于自定义类）。有人告诉我，他们这样做是因为他们遇到了一些奇怪的泄漏，这些泄漏有时会在使用自定义类并在 viewDidUnload 中取消其属性时出现（因为将 nil 设置为属性有时不会释放这些 ivar 对象）

只是想知道为什么应该在使用属性和合成时，我费心使用 ivar 声明来完成所有需要的事情。我什至可以直接使用它们的名称来访问 ivars，而无需在 dealloc 中使用 self。那么，有人对此有疑问吗？或者你们中的许多人仍然坚持旧的声明约定？

@interface ContactModel : NSObject {

  NSString *_firstName;
}

@property (nonatomic, retain) NSString *firstName;

@end

@implementation ContactModel

@synthesize firstName = _firstName;

-(void)dealloc{
  [_firstName release];
  [super dealloc];
}
@end

还应该注意的是，Apple 在生成主应用程序委托类文件并合成 window=_window 时仍然使用旧的声明样式。嗯，目前，我对应该采取什么约定有点困惑，所以欢迎任何想法:)

Answer 1

在现代运行时，您不需要 ivar 声明，但合成 a=_a 仍然有助于区分 self.a （访问器）和 _a （直接访问）。如果 @property/@synthesize 泄漏了，我想我们现在应该知道了。

据我所知，仅当您想要 @protected 访问（仅访问子类）或支持旧运行时时，使用 ivars 而不是属性才有用。

在 dealloc 中，无论您是否使用 ivar 声明和 @properties，都应该直接释放该属性，并且可以选择 你可以为零或不。

Answer 2

我喜欢“老方法”，因为我喜欢一致性和（更重要的是）封装。

一致性

就我个人而言，我只是想通过查看一个地方来很好地了解对象的大小和复杂性。

示例：当您实现 dealloc 时，您是否更喜欢引用多个位置？不是我。这比必要的更复杂。我不想通过从所有 ivars 和属性创建一个集合来弄清楚我需要清理什么。单独的属性是不够的，因为它们最终也会出现在多个地方（接口、私有类别）=\，

所以在我看来，较小的邪恶是声明 ivars，这样所有的东西都在一个地方，你可以快速引用对象的复杂性（以及对于某些代码生成器来说是一个很好的输入）。

封装

当你看到一个程序，其中大多数对象的ivars/属性都是可见的并且是可读/可写的......这不是OOD，而是一团糟。当你需要礼貌地描述它时，它就是反模式“对象狂欢”。不幸的是，它在 objc 程序中相对常见（部分由于语言/运行时限制）。

带有前缀下划线的 ivars：就个人而言，我不在 objc 中使用该约定。如果他们的代码就是这样写的，那就用它吧（没什么大不了的）。

他们还表示，仅当需要外部访问 ivars 时才使用属性，而对于内部访问，他们使用直接 ivars（用于自定义类）。

正确 - 这就是尝试封装的地方。顺其自然并接受适当的封装。

我被告知他们这样做是因为他们遇到了一些奇怪的泄漏，这些泄漏有时会在使用自定义类并在 viewDidUnload 中将其属性置空时出现（因为将 nil 设置为属性有时不会释放这些 ivar 对象）< /p>

理想情况下，他们会为您提供了更好的解释（并找到了当时具体问题的根源）。

他们的神秘程序很可能没有对其成员（数据）、接口及其执行做出足够清晰的区分。当这些重叠时，失去所有权的情况并不少见。这种情况是组织混乱和/或实施超出预期的普遍迹象。如果你正确地组织/编写类，ivar/属性跟踪非常简单（大概，他们通过支持封装而取得了进展）。同样，protected 是默认可见性；我建议您将 private 作为默认值。

只是想知道为什么我在使用属性和合成时要费心使用 ivar 声明来完成所有需要的事情。我什至可以直接使用它们的名称来访问 ivars，而无需在 dealloc 中使用 self。那么，有人对此有疑问吗？或者你们中的许多人仍然坚持旧的声明约定？

• 设计良好的程序不是由数据 blob（具有公共或属性可访问变量）组成。
• 在大多数情况下，状态（例如ivars）不应直接映射到接口。
• 使您的数据和行为对其他人隐藏得很好。
• 即使“私有”属性也可能很容易出错（它们的选择器可能被执行或覆盖）。
• 当 private 是您的默认值并且 ivar 确实无法从外部访问时，您可以降低很多复杂性。

所以...我认为他们提出这个请求是为了通过减少对状态的外部暴露并最终减少程序的复杂性来使您的生活更简单。他们承认过去遇到过问题，并且正在尝试使用封装来降低复杂性和出错的机会。对他们有好处。

我知道，有些程序员只是喜欢所有公开可见和可变的东西 - 编写程序来支持这种复杂程度并不是对时间的有效利用，而现实是大多数这样做的人都这样写如果没有远见或耐心来正确编写这样的程序，就会给其他人带来麻烦。当然，它过去可能对您有用，但这是一种幼稚的方法，当您与团队合作时，您没有机会编写所有程序。因此，你不能假设他们已经完整地阅读并理解了你编写的每个程序。

通过隐藏您可以隐藏的内容，使您的程序具有用户/防错性，并使它们与您团队的风格保持一致。

（从技术上讲还有一些额外的好处，我不会在这里详细说明）