使用ARC，@property是否必要？

Question

使用自动引用计数（ARC）时，默认情况下，每个指针赋值都会执行保留操作。在这种情况下，在非原子情况下，我为什么还需要声明属性呢？

这两者有何不同？

//Property
@interface I1 : NSObject 
@property (nonatomic, strong) NSString* str;
@end

I1 *obj1 = ...;
obj1.str = [[NSString alloc] init...];

//Only member variable
@interface I2 : NSObject { 
@public
    NSString* str;
}
@end
I2 *obj2 = ...;
obj2->str = [[NSString alloc] init...];

- RajV

---

这个问题听起来非常像iOS：每个iVar都必须是属性吗？。其他相关问题：为什么要使用ivar？ - Sam

Answer 1

属性是 面向对象编程 的一部分，这就是封装！它们为什么不能使用？！始终使用属性来封装您的数据。

- beryllium

---

如果在@implementation中声明了一个ivar，那么就存在封装性，因此在这种情况下有讨论的余地。 - zaph

在上述非原子情况下，属性几乎没有任何封装性。在ARC之前，当然，让属性执行保留/释放操作是有价值的。 - RajV

Answer 2

@property/@synthesize对自动生成getter和setter起到了作用，从而实现了封装。

当然，当前可能并不需要这种封装，但是也许在未来，您会决定为iVar添加一些惰性初始化，或者希望在iVar的内容更改时发布通知。始终使用属性和合成或手动编写的访问器是一个好习惯，而且成本微不足道。那么，为什么不使用它们呢？

（如果您担心@property/@synthesize过于繁琐，并且您拥有Mac Dev帐户，请查看Beta论坛。）

- fzwo

---

我认为这里提出的关于未来可能从财产中获益的论点是有效的。但是，我的问题纯粹根源于现在。至于为什么我不会使用财产的问题是错误的。任何行动都必须有理由支持。仅仅因为一项行动没有积极或消极的影响，并不意味着一个人应该盲目地去做它。 - RajV

@RajV 好的代码方面之一是可维护性，因此，如果您想就纯粹的现在进行争论，那么问题就变得学术化了。实际上，访问器是更好的选择，因为它们可以提高可维护性，而不会在现在造成任何损失。出于这个原因，我认为应该养成使用它们的习惯（除了私有iVars和真正需要考虑性能的东西之外）。 - fzwo

@fzwo，可能过度的是在访问实例变量时通过属性来访问（self.ivar vs ivar），特别是当实例变量在@implementation中声明时，因此只局限于单个文件。在这种情况下，稍后更改为属性仅影响一个文件和类。请注意，我并不是在争论哪种方式更好。 - zaph

Answer 3

内存管理并不是使用属性的唯一优点。我能想到的两个特别之处是：

1. 键值观察（无需手动调用 willChangeValueForKey: 和 didChangeValueForKey: - 参见手动更改通知）
2. 能够编写自定义逻辑来设置和获取器，以及编写子类定制化的设置和获取器。

bbum在 iOS: must every iVar really be property? 中对此做出了很好的回答。

- Sam

---

是的，这些好处肯定会支持属性的需求。 - RajV

Answer 4

我认为属性仍然用于自动生成访问器和修改器，而不使用@public。

- James Webster

---

在这里提出的非原子情况下，生成的访问器/修改器必须是如此微不足道，以至于不必要。这是核心问题。我们甚至需要属性吗？ - RajV

需要考虑KVO。 - zaph

Answer 5

在接口中使用 @property，因为它表示公开访问。如果您不想实际将其设为公开的，请将 @property 声明放在类扩展中或在 .m 文件的 @implementation 中进行 ivar 声明。

- zaph

Answer 6

在Objective-C中，@property只是一个类中标准setter和/或getter的缩写。因此，无论您的ARC选项是开启还是关闭，您都可以自行选择。

- shadowglen