使用ARC为什么再使用@properties？

Question

在非ARC代码中，保留属性可以使用self.property =语法为您轻松处理内存管理，因此我们被教导几乎可以使用它们。

但是现在使用ARC这种内存管理不再是问题，使用属性的原因是否会消失？还有什么好的理由（显然除了提供对实例变量的公共访问权限之外）才能再使用属性了吗？

Answer 1

  

但是现在使用ARC，这种内存管理不再是问题，也是如此   使用属性蒸发的原因是什么？还有什么好处   原因（显然不是提供对实例的公共访问权限   变量）再使用属性了吗？

是的 - 通过使用@property和@synthesized getters / setter，您可以保证：

• 您的getter / setter可以是子类，子类可以覆盖存储和/或行为
• 一切都很好地封装了
• 您可以使用观察挂钩 - KVO等...... - 监控内部和外部的变化
• 您可以方便地在读取和/或写入属性时设置断点
• 如果需要公开“仅内部”实例变量，则需要复制@property声明本身;更少的重构。
• 你可以利用所有各种修饰符关键字的声明能力 - 复制，强，弱，原子等。 - 编译器越来越有利于过度使用

即使是内部的类，我通常倾向于使用属性和点语法来维护对象内的状态。这并非普遍正确 - 如果我的设计是暴露意味着无论如何都会进行大规模的重构，那么我会直接操作一些实例变量（完全直接操作;根本没有@property）。

Answer 2

  

使用属性的原因是什么？

随着ARC为ivars提供“所有权魔力”，人们为什么选择ivars属性的这个特殊方面确实消失了。但是，还有许多其他人仍然存在：

• 原子/非原子区分可用于属性，而不适用于ivars
• 属性提供的灵活性（readonly / read + write区分）不适用于ivars
• 执行计算和参数检查的能力不适用于ivars

我继续使用属性作为保持可能暴露给外部类或内部“兄弟”类的状态的默认方式，因为额外的灵活性超过了运行时的额外成本。

Answer 3

我不认为我曾经仅仅因为内存管理而使用过属性而且我认为你不应该这样做。所以要回答你的问题，不，没有理由使用除了访问实例变量之外的其他属性，这实际上就是他们应该首先使用它们。

Answer 4

你在谈论两件不同的事情。 ARC用于管理内存，因此您不必承担大量的dealloc和retain语句。

属性可以让类有机会控制/限制其内部iVars的暴露，为其他类公开API以进行通信/交互。

Answer 5

除了保留之外，还有其他修饰语有时会变得非常有用，例如：将块分配给类成员变量时为“copy”，或者确保无法写入属性的“readonly”。使用Core Data时也不要忘记'dynamic'属性，以及在分配或检索属性时执行自定义代码的可能性（定义自定义getter / setter而不是使用@synthesize时）。