ARC下的属性：始终还是仅公开？

在不到两年前，阅读了Robert McNally谦虚的文章“代码指令：Objective-C编码的最佳实践”之后，我采用了对我的Objective-C类的几乎每个数据成员使用属性的做法（ （截至2012年5月的第三条诫命）。McNally列出了这样做的原因（我的重点）：

1. 属性强制执行访问限制（例如只读）
2. 属性强制执行内存管理策略（强，弱）
3. 属性提供了透明实现自定义setter和getter的机会。
4. 具有自定义setter或getter的属性可用于强制执行线程安全策略。
5. 使用单一方法访问实例变量可提高代码的可读性。

我将大多数属性都归为私有类别，因此编号1和4通常不是我遇到的问题。参数3和5更加“柔和”，并且使用正确的工具和其他一致性，它们可能会成为问题。最后，对我而言，这些论点中最具影响力的是数字2，内存管理。从那时起，我一直在这样做。

@property (nonatomic, strong) id object; // Properties became my friends.

在我的最后几个项目中，我转而使用ARC，这使我怀疑为几乎所有内容创建属性仍然是个好主意还是有点多余。ARC为我负责内存管理Objective-C对象的管理，strong如果您声明ivars ，则对于大多数成员而言，它可以正常工作。无论如何，在ARC之前和之后，您都必须手动管理C类型，并且这些weak属性大部分是公共属性。

当然，对于需要从类外部访问的任何内容，我仍然使用属性，但是这些属性仅是少数几个属性，而大多数数据成员在实现标头下被列为ivars。

@implementation GTWeekViewController
{
    UILongPressGestureRecognizer *_pressRecognizer;
    GTPagingGestureRecognizer *_pagingRecognizer;
    UITapGestureRecognizer *_tapRecognizer;
}

作为一个实验，我更加严格地执行了此操作，并且从所有属性移开属性都有一些不错的积极副作用。

1. 数据成员代码要求（@property/ @synthesize）缩小为ivar声明。
2. 我的大部分self.something参考资料都整理到_something。
3. 可以轻松地区分哪些数据成员是私有的（无效）和哪些数据成员是公共的（属性）。
4. 最后，“感觉”起来更像是苹果打算将其用于房地产的目的，但这是主观的猜测。

关于一个问题：我正在慢慢地向黑暗面发展，使用越来越少的属性来支持实现错误。您能否为我提供一些理由，说明为什么我应该坚持对所有内容都使用属性，或者证实我当前的思路，为什么我应该仅在需要的地方使用更多的ivars和更少的属性？双方最有说服力的答案都会得到我的认可。

编辑：麦克纳利（McNally）在推特上说：“我认为坚持使用房地产的主要理由是：一种做所有事情的方法，那就是做所有事情（包括KVC / KVO）。”

您能否为我提供一些理由，说明为什么我应该坚持对所有内容使用属性，或者确认我目前的思路，为什么我应该仅在需要的地方使用更多的ivars和更少的属性？

现在，我认为可以说这主要是风格问题。如您所说，属性在内存管理方面的优势在ARC中并不那么重要。另一方面，回到直接ivar访问的“好处”也不是很吸引人：

1. @property声明与ivar声明非常相似。避免使用@synthesize指令似乎不是一个大胜利-我们谈论的不是很多代码。

2. 该foo.something语法可以说是很多好过_something。属性访问语法显然设计成看起来和像C的点语法一样工作，用于访问结构的成员。明确说明您正在访问哪个对象（无论是那个self还是其他）是有帮助的。（self->something出于这个原因，有人-不是我！-提倡使用ivar。）ivars的主要下划线约定是可以的，但是并不是所有的Objective-C代码都一致地使用它。

3. 对于访问存储在同一类的其他对象中的数据（“私有”访问权限允许）和子类的访问（例如C ++的“保护”），属性似乎是一个更好的选择。因此，“属性==公共”的概念有些模糊。

4. 我的感觉是属性旨在简化内存管理并提供其他一些好处。就像您说的那样，随着内存管理优势的降低，属性似乎不那么引人注目。

您选择的路径-回到直接对内部数据进行ivar访问-似乎是一个非常合理的选择，没有明显的理由改变您的课程。但是坚持属性也是很合理的-缺点并不明显，并且还有一些不错的好处，例如KVO合规性和更一致的成员访问风格。

属性并不是Objective-C发展的最后一步，而且我也不希望ARC会是。我没有任何具体信息，但是似乎可以猜测，可能会在某个时候添加一些附加功能，这些附加功能会使属性变得更引人注目或更少。我们将不得不等待，看看会发生什么。

我也一直在思考这个问题。以我的拙见，仅对访问器使用属性会使代码更具可读性。您可以立即看到要公开访问的变量。就个人而言，始终在变量前面键入@property（...）非常耗时。