用ARC为什么使用@properties了？
在非ARC代码保留属性中，使用self.property =语句轻松地为您pipe理内存pipe理，所以我们被教导将其用于几乎所有的事情。
但是现在使用ARC这个内存pipe理已经不再是一个问题了，那么使用属性的原因是什么呢？ 还有什么好的理由（显然除了提供公共访问实例variables）使用属性了吗？
但是现在使用ARC这个内存pipe理已经不再是一个问题了，那么使用属性的原因是什么呢？ 还有什么好的理由（显然除了提供公共访问实例variables）使用属性了吗？
是的 – 通过使用@property和@synthesized getters / setters，你保证：
- 你的getter / setter可以被子类化，子类可以覆盖存储和/或行为
- 一切都很好地封装
- 您可以使用观察钩 – KVO等 – 监视内部和外部的变化
- 你有一个方便的地方设置一个断点读取和/或写入属性
- 如果需要暴露“仅内部”实例variables，则需要复制@property声明本身; 更不用说重构了。
- 你可以利用所有各种修饰语关键词的声明能力 – 复制，强，弱，primefaces等。 – 编译器正在越过thime
即使在内部，我通常依靠属性和点语法维护对象内的状态。 这不是普遍的真理 – 如果我的devise是这样的，那么暴露就意味着大量的重构，那么就会有一些我直接操纵的实例variables（ 完全直接操纵;根本就没有@property）。
那么使用属性蒸发的原因是什么？
随着ARC为“ivars”提供“所有权魔法”，为什么select属性超过ivars的这个特定方面确实会蒸发。 但是，还有很多其他的：
- primefaces/非primefaces的区别是可用的属性，而不是为ivars
- 属性提供的灵活性（readonly / read + write的区别）不适用于ivars
- 执行计算和参数检查的能力不适用于ivars
我继续使用属性作为保持可能暴露于外部类或内部“兄弟”类的默认方式，因为额外的灵活性超过了运行时的小额外成本。
我不认为我只是因为内存pipe理而使用过属性，我不认为你应该这样做。 因此，为了回答你的问题，不，没有理由使用除访问实例variables之外的属性，这本质上是它们应该首先使用的。
你在谈论两件不同的事情。 ARC是用来pipe理内存的，所以你不必担心大量的dealloc和保留语句。
属性是为了让一个类有机会控制/限制其内部iVars的暴露，暴露一个API来与其他类进行通信/交互。
除了保留之外，还有其他修饰符有时可能变得非常有用，例如，在将块分配给类成员variables时进行“ copy ”，或者确保属性无法写入的“ readonly ”。 在使用核心数据时，不要忘记“ dynamic ”属性，以及在分配或检索属性时（定义自定义getter / setter而不是使用@synthesize时）执行自定义代码的可能性。