iOS，使用下划线和直接使用iVar [英] iOS, using underscore vs using iVar directly
问题描述
这已经被问了很多，但这个问题是获得例子，当你将使用这些方法的每一个。请使用除setter和getter infinite循环之外的示例
示例。
.h -
@property（nonatomic，strong）NSMutableArray * mutArray
.m -
@synthesize mutArray = _mutArray;
1）我想要：
_mutArray = [[NSMutableArray alloc] init];
OR
self.mutArray = [[NSMutableArray alloc] init];
为什么我会做它们中的每一个，有什么区别？
2）如果我想向其中添加一个对象...
[_ mutArray addObject：object];
OR
[self.mutArray addobject：object];
为什么?!
非常感谢！
你应该只处理你的ivars在 init 和 dealloc 或实现细节绝对需要的地方（例如访问器本身内部，或者实际需要内存地址的地方）。除了这些地方，你应该总是使用访问器，这意味着 [self foo] 而不是 _foo 。 / p>
self.foo 只是实际调用的语法糖， [self foo ] 。重要的是要理解 self.foo 是标准的ObjC消息发送，意味着与 [self foo] 。按照惯例，在引用属性时，您应该只使用点语法。
Pre-ARC，直接使用ivars是我的经验崩溃的第一个原因。
从ARC开始，我仍然认为你应该永远在这个角色使用访问器（除了上面给出的例外），但原因更为微妙。它的主要原因是一个访问器可以在当前类，在一个子类，或通过KVO（这发生在你的代码之外完全）。如果你直接访问ivar，那么你会绕过这个。例如，说属性是lazily创建的（这是很常见）。然后如果你在创建之前使用ivar，你会得到微妙的bug。所以你必须记住，对于那个属性，总是使用访问器。类似地，您可以调用 setNeedsDisplay 或发布通知等。
如果你有一个简单的规则，说我会总是使用访问器，那么很容易看看代码，知道它是正确的。在少数情况下，你需要绕过访问器， _ 说hey，注意这里，我做一些奇怪的事情。
如果你有一个规则我将使用访问器的属性需要它，但不是那些没有，那么几乎不可能查看代码，知道它是否正确。以前的开发人员使用ivar，因为它是必需的或只是因为他觉得呢？你能改变吗？这是很难知道。
所以即使是ARC之后，使用访问器仍然是良好的防御性编程，我强烈推荐它。
This has been asked a lot, but this question is to get examples of when you would use each of these methods. Please use examples other than the setter and getter infinite loop
example.
.h -
@property(nonatomic, strong)NSMutableArray* mutArray
.m -
@synthesize mutArray= _mutArray;
1) would I want:
_mutArray = [[NSMutableArray alloc] init];
OR
self.mutArray=[[NSMutableArray alloc] init];
Why would I do each of them, and what is the difference?!
2) If I want to add an object to it...
[_mutArray addObject:object];
OR
[self.mutArray addobject:object];
and why?!
Thanks so much!
You should only deal with your ivars in init and dealloc or where absolutely required by an implementation detail (such as inside of the accessor itself, or where you actually require a memory address). Other than in those places, you should always use the accessor, which means [self foo] rather than _foo.
self.foo is just syntactic sugar around the actual call, which is [self foo]. It is important to understand that self.foo is a standard ObjC message-send, and means exactly the same thing as [self foo]. By convention, you should only use dot-syntax when referring to properties.
Pre-ARC, direct use of ivars was the #1 cause of crashes in my experience. The likelihood of you screwing up when assigning directly to an ivar without ARC quickly approaches 100% over the scope of the program.
Since ARC, I still argue that you should always use accessors (with the exceptions given above), but the reasons are more subtle. The main reason for it is that an accessor may be customized, either in the current class, in a subclass, or via KVO (which happens outside your code entirely). If you directly access the ivar, then you will bypass this. For example, say the property is lazily-created (which is pretty common). Then if you use the ivar before it's created, you'll get subtle bugs. So you have to remember, for that property, to always use the accessor. Similarly, you might call setNeedsDisplay or post a notification, or the like.
If you have a simple rule that says "I will always use accessors" then it's easy to look at the code and know it's right. In the few cases you need to circumvent the accessor, the _ says "hey, pay attention here, I'm doing something weird."
If you have a rule "I will use accessors for properties that need it, but not for ones that don't" then it's almost impossible to look at the code and know whether it's correct. Did the previous developer use the ivar because it was required or just because he felt like it? Can you change it or not? It's very hard to know.
So even post-ARC, using accessors consistently is good defensive programming and I highly recommend it.
这篇关于iOS，使用下划线和直接使用iVar的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
