我应该在 Objective-C 中使用 ivars 吗？
我正在编写一个仅使用@properties 的应用程序。我的任何类文件中都没有声明任何 ivar。据我了解，随着@property的引入，不再需要ivars。我是否按照最佳实践进行编码？从长远来看，这最终会咬我的屁股吗？我一直在阅读关于什么是“正确”和“错误”的褒贬不一的评论......
I have an application that I'm writing that uses solely @properties. I have not one ivar declared at all in any of my class files. As I understand it ivars are no longer needed with the introduction of @property. Am I coding according to best practice? Will this end up biting me in the proverbial butt in the long term? I have been reading mixed reviews on what is "right" and "wrong"...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
并不是说不需要实例变量。只是不需要实例变量声明。给定一个属性和一个 @synthesize 语句，编译器将负责创建实例变量以及适当的访问器方法。
专门使用属性并没有什么问题。它们简化了内存管理。如果您想要的话，使用不带属性的 iVar 也没有问题。如果您想使用属性，但不想向世界其他地方公布访问器（即维护封装），请考虑在类扩展中声明您的非公共属性（基本上是实现文件中的匿名类别）。
It's not so much that instance variables aren't needed. It's just that instance variable declarations aren't needed. Given a property and a @synthesize statement, the compiler will take care of creating the instance variable along with appropriate accessor methods.
There's nothing wrong with using properties exclusively. They simplify memory management. There's also nothing wrong with using iVars without properties, if that's what you want. If you want to use properties but don't want to advertise the accessors to the rest of the world (i.e. maintain encapsulation), consider declaring your non-public properties in a class extension (basically an anonymous category in your implementation file).
我一般也不声明 ivars。
我经常使用而且我总是让编译器自动合成 ivar带有@synthesize foo = foo_;来防止直接访问，而我的意思是通过方法，反之亦然。_前缀（根据struck短语，防止意外直接访问）。而且，正如 Caleb 所说，仍然有 ivars 浮动，你只是不显式声明它们，除非你真的想要（实际上，你不会这样做，因为标头中暴露的 ivars 对类的客户端没有用处） ，如果您的 API 设计得当）。
我还发现，关于“仅在 init/dealloc 中使用直接访问，在其他地方使用 setter/getter”的宣传在很大程度上被夸大了，因此，只需在任何地方使用 setter/getter 即可。现实情况是，如果你在初始化/释放期间有观察者，那么你已经被淹没了；根据定义，对象的状态在构造/销毁期间是未定义的，因此观察者不可能正确地推理该状态。
正如 Caleb 指出的，在 init/dealloc 中使用直接 ivar 访问的另一个原因是避免子类实现自定义 setter/getter 逻辑，这些逻辑可能会由于 init/dealloc 期间对象的未定义状态而导致失败。
虽然这可能是真的，但我认为用自定义行为实现 setter/getter 是一个令人讨厌的架构缺陷。这样做很脆弱，并且随着时间的推移，重构代码会变得更加困难。同样，此类自定义行为通常会依赖于对象内的其他状态，并且该依赖关系会导致对状态更改的顺序依赖，而这些状态更改根本不会通过看似简单的
@property声明反映出来。即，如果您的 setter 和 getter 编写为
foo.bar = bad;无法在foo上任何时间执行，那么您的代码是被抓了。I generally don't declare ivars, either.
I will often useAnd I always let the compiler automatically synthesize the ivar with the@synthesize foo = foo_;though to prevent direct access when I meant through-method or vice-versa._prefix (which prevents accidental direct access, as per thestruckphrase).And, as Caleb said, there are still ivars floating about, you just don't explicitly declare 'em unless you really want to (which, really, you don't as exposed ivars in the headers are not useful to clients of the class, if your API is designed appropriately).
I also find that the hype over "only use direct access in init/dealloc, use setter/getter everywhere else" to be largely overblown and, thus, just use the setter/getter everywhere. The reality is that if you have observers during initialization/deallocation, you are already hosed; the state of the object is, by definition, undefined during construction/destruction and, thus, an observer can't possibly reason correctly about the state.
As Caleb points out, another reason to use direct ivar access in init/dealloc is to avoid subclasses that implement custom setter/getter logic that may barf due to the undefined state of the object during init/dealloc.
While this may be true, I consider it a nasty architectural flaw to implement setters/getters with custom behavior. Doing so is fragile and makes it significantly more difficult to refactor the code over time. As well, such custom behavior will often have dependency on other state within the object and that dependency then leads to order dependencies on state changes that are not at all reflected by the seeming simple
@propertydeclaration.I.e. if your setters and getters are written such that
foo.bar = bad;cannot be executed at any time onfoo, then your code is busted.使用 iVars 当然没有错，但是现在的最佳实践确实提倡使用 @property。
Using iVars certainly isn't wrong, however best practises now do push for using @property instead.
您可能想要使用 ivar 的一个地方是当您想要声明受保护的属性时。您可以在 .m 文件中为类声明属性，并使用 @protected 指令在 .h 中声明其相应的 ivar。这将使您在子类中拥有受保护的访问权限。没有其他选择可以保护成员的访问。
One place where you may want to use an ivar is when you want to declare a protected property. You declare the property in the .m file for a class, and declare its corresponding ivar in the .h with the @protected directive. This will then let you have a protected access in the subclass. There's no alternative for protected access to members.