我应该在Objective-C中使用ivars吗？

Question

我正在编写一个仅使用@properties的应用程序。我的任何课程文件中都没有宣布任何一个ivar。据我所知，随着@property的推出，不再需要ivars了。我是按照最佳做法编码的吗？从长远来看，这最终会在众所周知的屁股中咬我吗？我一直在阅读关于“正确”和“错误”的评论......

Answer 1

并不需要实例变量。只是不需要实例变量声明。给定一个属性和@synthesize语句，编译器将负责创建实例变量以及适当的访问器方法。

独占使用属性没有任何问题。它们简化了内存管理。使用没有属性的iVars也没什么不对，如果那就是你想要的。如果您想使用属性但不想将访问器通告给世界其他地方（即维护封装），请考虑在类扩展中声明非公共属性（基本上是实现文件中的匿名类别）。 / p>

Answer 2

我通常也不会宣布伊娃。 我会经常使用@synthesize foo = foo_;来阻止直接访问，当我的意思是通过方法，反之亦然。我总是让编译器自动合成带有_前缀的ivar （根据 struck 短语，防止意外直接访问）。

而且，正如Caleb所说的那样，仍然存在一些问题，你只是没有明确地声明'em，除非你真的想要（实际上，你不会因为标题中暴露的ivars对客户没用）如果您的API设计得恰当，则为该类。

我还发现炒作“只使用init / dealloc中的直接访问，在其他地方使用setter / getter”在很大程度上被夸大了，因此，只需在任何地方使用setter / getter。现实情况是，如果你在初始化/解除分配期间有观察员，你已经被冲洗了;根据定义，在构造/破坏期间，对象的状态是未定义的，因此，观察者不可能正确地推断出状态。

---

正如Caleb所指出的，在init / dealloc中使用直接ivar访问的另一个原因是避免实现自定义setter / getter逻辑的子类，这些逻辑可能会因init / dealloc期间对象的未定义状态而变为barf。

虽然这可能是真的，但我认为用自定义行为实现setter / getter是一个令人讨厌的架构缺陷。这样做很脆弱，因此随着时间的推移重构代码变得非常困难。同样，这种自定义行为通常依赖于对象中的其他状态，然后该依赖性会导致对状态更改的顺序依赖性，而这些状态更改完全不会被看似简单的@property声明所反映。

即。如果你的setter和getter被写成foo.bar = bad;无法在任何时间foo执行，那么你的代码就会被破坏。

Answer 3

使用iVars当然没有错，但是现在最好的做法是推动使用@property。

Answer 4

您可能想要使用ivar的地方是您想申报受保护的财产。您在.m文件中为类声明该属性，并使用@protected指令在.h中声明其对应的ivar。这将使您在子类中具有受保护的访问权限。对成员的受保护访问没有其他选择。