iOS, using underscore vs using iVar directly [closed]

问题

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!

回答1:

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.

回答2:

self Is keyword like this keyword in JAVA.

It access to current object and also It is a pointer to an object.

for more info about self read this tutorial

_ObjeName is called iVar in Objective c

Instance variables declared in the implementation are implicitly hidden (effectively private) and the visibility cannot be changed - @public, @protected and @private do not produce compiler errors (with the current Clang at least) but are ignored.

For Example :

Different between

1) NSString *someString = _name;

2) NSString * someString = self.name;

Assume you have in your .m file this line (and don't have any overriden methods to direct access to _name)

@synthesize name = _name;

It mean that property name (self.name) will use variable _name when you try to access it. In this case self.name is equal to _name

But if you have dynamic property for name, something like this :

-(NSString)name{
    return @"1234";
}

then there is a difference. self.name will always return 1234, but _name can be not equal to this value.

Example:

_name = @"555";
NSLog(_name);
NSLog(self.name);

Result:

2012-02-09 14:27:49.931 ExampleApp[803:207] 555
2012-02-09 14:27:49.933 ExampleApp[803:207] 1234

Above Example I Got From this Question.

回答3:

_mutArray is the iVar, self.mutArray accesses the property through getters and setters which are created for you when you @synthesize the property. You can overwrite these getters and setters to due custom stuff. In your example, you're property is set to strong, which adds a retain to your property. So self.mutarray = [[NSMutableArray alloc] init]; would do something like this (unless you over-write the property's setter):

-(void)setMutarray:(NSMutableArray*)_mutArray{
    if(_mutArray != mutArray){
        [mutArray release];
        mutArray = nil;
        mutArray = [_mutArray retain];
    }
}

For adding objects to an array you would want to just access the iVar, not the property unless you are doing something custom in the getter. For example you're getter might look like this:

-(NSMutableArray*)mutArray{
    if(!mutArray){
        self.mutArray = [[[NSMutableArray alloc] init] autorelease];
    }
    return mutArray;
}

in this way you could ensure that you always had a real array to add objects to. If this is the case you would want to use [self.mutArray addObject:object];

So, unless you want to do something custom in the getter or setter you just want to access the iVar.

来源：https://stackoverflow.com/questions/15644386/ios-using-underscore-vs-using-ivar-directly

标签

iphone

ios

objective-c

cocoa-touch

ivar