为什么要使用 ivar? [英] Why would you use an ivar?

问题描述

我通常看到这个问题以另一种方式被问到，例如必须每个 ivar成为财产?(我喜欢 bbum 对这个问题的回答).

I usually see this question asked the other way, such as Must every ivar be a property? (and I like bbum's answer to this Q).

我几乎只在我的代码中使用属性.然而，我经常与一位长期在 iOS 上进行开发并且是传统游戏程序员的承包商合作.他编写的代码几乎不声明任何属性，并且依赖于 ivars.我认为他这样做是因为 1.) 他已经习惯了，因为直到 Objective C 2.0(2007 年 10 月)和 2.) 属性才一直存在，以实现不通过 getter/setter 的最小性能增益.

I use properties almost exclusively in my code. Every so often, however, I work with a contractor who has been developing on iOS for a long time and is a traditional game programmer. He writes code that declares almost no properties whatsoever and leans on ivars. I assume he does this because 1.) he's used to it since properties didn't always exist until Objective C 2.0 (Oct '07) and 2.) for the minimal performance gain of not going through a getter / setter.

虽然他编写的代码不会泄漏，但我仍然更喜欢他使用属性而不是 ivars.我们讨论过这个问题，他或多或少认为没有理由使用属性，因为我们没有使用 KVO，而且他在处理内存问题方面经验丰富.

While he writes code that doesn't leak, I'd still prefer him to use properties over ivars. We talked about it and he more or less sees not reason to use properties since we weren't using KVO and he's experienced with taking care of the memory issues.

我的问题更多...你为什么要使用 ivar 周期 - 无论是否有经验.使用 ivar 真的有那么大的性能差异吗?

另外作为澄清的一点，我根据需要覆盖 setter 和 getter，并使用与 getter/setter 内部的该属性相关的 ivar.但是，在 getter/setter 或 init 之外，我总是使用 self.myProperty 语法.

Also as a point of clarification, I override setters and getters as needed and use the ivar that correlates with that property inside of the getter / setter. However, outside of a getter / setter or init, I always use the self.myProperty syntax.

感谢所有的好评.我想解决的一个似乎不正确的问题是，使用 ivar 可以获得封装，而使用您没有的属性.只需在类延续中定义属性.这将向外界隐藏该财产.您还可以在接口中声明属性为只读，并在实现中将其重新定义为可读写，例如:

I appreciate all of the good responses. One that I'd like to address that seems incorrect is that with an ivar you get encapsulation where with a property you don't. Just define the property in a class continuation. This will hide the property from outsiders. You can also declare the property readonly in the interface and redefine it as readwrite in the implementation like:

// readonly for outsiders
@property (nonatomic, copy, readonly) NSString * name;

并在课堂上继续:

// readwrite within this file
@property (nonatomic, copy) NSString * name;

要让它完全私有"，只需在类延续中声明它.

To have it completely "private" only declare it in the class continuation.

推荐答案

封装

如果 ivar 是私有的，程序的其他部分就不能那么容易地得到它.使用声明的属性，聪明的人可以通过访问器很容易地访问和改变.

Encapsulation

If the ivar is private, the other parts of the program can't get at it as easily. With a declared property, the clever people can access and mutate quite easily via the accessors.

是的，这在某些情况下会有所作为.有些程序有一些限制，它们不能在程序的某些部分使用任何 objc 消息传递(想想实时).在其他情况下，您可能希望直接访问它以提高速度.在其他情况下，这是因为 objc 消息传递充当优化防火墙.最后，它可以减少您的引用计数操作并最大限度地减少峰值内存使用(如果操作正确).

Yes, this can make a difference in some cases. Some programs have constraints where they can not use any objc messaging in certain parts of the program (think realtime). In other cases, you may want to access it directly for speed. In other cases, it's because objc messaging acts as an optimization firewall. Finally, it can reduce your reference count operations and minimize peak memory usage (if done correctly).

示例:如果您有 C++ 类型，有时直接访问只是更好的方法.类型可能无法复制，或者复制可能不是微不足道的.

Example: If you have a C++ type, direct access is just the better approach sometimes. The type may not be copyable, or it may not be trivial to copy.

您的许多 ivars 是相互依赖的.您必须确保多线程上下文中的数据完整性.因此，您可能更喜欢直接访问临界区中的多个成员.如果您坚持使用访问器来获取相互依赖的数据，那么您的锁通常必须是可重入的，而且您通常最终会进行更多的获取(有时明显更多).

Many of your ivars are codependent. You must ensure your data integrity in multithreaded context. Thus, you may favor direct access to multiple members in critical sections. If you stick with accessors for codependent data, your locks must typically be reentrant and you will often end up making many more acquisitions (significantly more at times).

由于子类可以覆盖任何方法，您最终可能会发现写入接口与适当管理状态之间存在语义差异.程序正确性的直接访问在部分构造的状态中尤其常见——在您的初始化程序和 dealloc 中，最好使用直接访问.您还可以在访问器、便利构造函数、copy、mutableCopy 和存档/序列化实现的实现中发现这种情况.

Since the subclasses can override any method, you may eventually see there is a semantic difference between writing to the interface versus managing your state appropriately. Direct access for program correctness is especially common in partially constructed states -- in your initializers and in dealloc, it's best to use direct access. You may also find this common in the implementations of an accessor, a convenience constructor, copy, mutableCopy, and archiving/serialization implementations.

随着人们从一切都具有公共读写访问器思维方式转变为一种很好地隐藏其实现细节/数据的思维方式，这种情况也更加频繁.有时您需要正确地绕过子类的覆盖可能引入的副作用，以便做正确的事情.

It's also more frequent as one moves from the everything has a public readwrite accessor mindset to one which hides its implementation details/data well. Sometimes you need to correctly step around side effects a subclass' override may introduce in order to do the right thing.

当您考虑一下程序的执行时，默认情况下声明所有内容为 readwrite 通常会导致许多您永远不需要的访问器方法.所以它会给你的程序和加载时间增加一些脂肪.

Declaring everything readwrite by default usually results in many accessor methods you never need, when you consider your program's execution for a moment. So it will add some fat to your program and load times as well.

在某些情况下，完全没有必要为一个简单的变量添加+类型+维护所有额外的脚手架，例如在一种方法中写入并在另一种方法中读取的私有 bool.

In some cases, it's just completely unnecessary to add+type+maintain all that extra scaffolding for a simple variable such as a private bool that is written in one method and read in another.

这并不是说使用属性或访问器不好——每个都有重要的好处和限制.与许多面向对象的语言和设计方法一样，您还应该支持在 ObjC 中具有适当可见性的访问器.有时您需要偏离.出于这个原因，我认为通常最好限制对声明 ivar 的实现的直接访问(例如，声明它@private).

That's not at all to say using properties or accessors is bad - each has important benefits and restrictions. Like many OO languages and approaches to design, you should also favor accessors with appropriate visibility in ObjC. There will be times you need to deviate. For that reason, I think it's often best to restrict direct accesses to the implementation which declares the ivar (e.g. declare it @private).

重新编辑 1:

我们大多数人都记住了如何动态调用隐藏的访问器(只要我们知道名称......).同时，我们中的大多数人没有记住如何正确访问不可见(超出 KVC)的 ivars.类延续有帮助，但它确实引入了漏洞.

Most of us have memorized how to call a hidden accessor dynamically (as long as we know the name…). Meanwhile, most of us have not memorized how to properly access ivars which aren't visible (beyond KVC). The class continuation helps, but it does introduce vulnerabilities.

这个解决方法很明显:

if ([obj respondsToSelector:(@selector(setName:)])
  [(id)obj setName:@"Al Paca"];

现在只用 ivar 试试，不用 KVC.

Now try it with an ivar only, and without KVC.

这篇关于为什么要使用 ivar?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！