Understanding and validation of "IOS" about attributes

There are attributes in iOS, and they are often used. We often write in the. h,.m file:

@interface** * *fourthnumber;  @end

This is the attribute, the individual understanding of the property is the ordinary variable plus some general rules, a bit like extension, at compile time compiler help us to generate something (guess, not verified).

First, the meaning of the attribute

Attributes have three functions:

1, define the variable, equivalent to make the following declaration in the program:

@interface Viewcontroller () {    *_firstnumber;     *_secondnumber;     *_thirdnumber;     *_fournumber;} @end

2, add modifiers to the generated variable

The modifier here is probably to the variable plus __strong,__weak, such as modifiers, the specific difference and contact is more complex, for the time being not here to say.

Here is a nonatomic to notice, when the declaration of the habit, all added. Its function is to indicate that the properties are non-atomic and correspond to atomic. iOS default does not write Nonatomic will be automatically considered to be atomic, and the atomic property itself is particularly resource-intensive, so if you do not want to make the program too card, please add nonatomic bar.

3, Generate Getter Setter function

The automatically generated function is the Get/set + first capitalization attribute name: -(NSNumber *) getfirstnum ();

Getter Setter functions can be defined, such as: @property (nonatomic, Getter=ison) BOOL on; so the corresponding getter function is -(BOOL) isOn (); Rather than -(BOOL) Geton ();

Two, the Get/set function related problems of the attribute

As stated above, the generated Get/set function is named after the Get/set + capitalized attribute name, so what happens when the first letter of the property name is capitalized? What happens when the letter of the function name get is lowercase? (note: In SSH, there may be a problem setting the property, where the default first letter if uppercase, the Get/set function defaults to the second letter uppercase ... And then a variety of wonderful rules.)

1, only the first letter case of different attributes, the generated Get/set function is the same drop! If you use it strongly, you will receive the compiler error, as follows:

@property (nonatomic, Strong) NSNumber **firstnumber; -(void) Setfirstnumber: (NSNumber *) firstnumber {    = firstnumber;}

　　

Looks good, as long as the naming specification is guaranteed, we can rewrite the Get/set function without a problem.

The 2,get/set function must capitalize the first letter of the property name, regardless of whether the first letter is uppercase or lowercase when the property name is defined. That

-(NSNumber *) getfirstnum (); √, can be overloaded normally

-(NSNumber *) getfirstnum (); X, overload fails and is not called

　　Third, attribute and _property variable, self.property and _property use

Now that the compiler will help us generate the _property variable after declaring the attribute, what if we have defined a variable named _property? What is the difference between calling Self.property and calling _property when using it?

1, after defining a property, there is no difference between defining a variable with the same name.

If you define a variable with the same name, the compiler will make an error, no doubt:

　　

After defining a property, the default is to generate an underlined variable with the same name, but if we define it ourselves, the compiler will not be superfluous, or we would understand that we have "overloaded" the system-generated variable (of course, the variable does not overload this thing). So we don't have to worry about defining both variables and attributes to cause error, but we should pay attention to the problem that the variable might be overwritten by the same name.

2, it is recommended to read the use of Direct access (_property) method, the storage time using the dot Syntax (Self.property).

This proposal is purely personal advice, and there is still intense discussion, and if you understand the rationale behind the various recommendations, users will be more reasonable in their own analysis and should not be suggested to be constrained.

The difference between the next point syntax and the direct access is distinguished first:

Using point syntax (self.property) calls the Getter/setter method according to the situation, and using _property is directly accessed by taking the variable out of memory directly. The specific differences are as follows:

1) The point syntax is to go through OC's "method dispatch" and direct access to the memory gain variable directly, so direct access is faster.

2) Point syntax calls the Getter/setter function, and direct access bypasses this. Even if we do not have to rewrite the Getter/setter function, if the setting property is copy, using point syntax will copy the object and then invoke it, while using direct access it is likely to change the original value directly (preserving the new value and releasing the old value).

3) using direct Access does not trigger "key-value observations" (Key-value observing, KVO) notifications. As to whether there is a problem, it is only you know ~

4) When using dot syntax, you can break points in the Getter/setter function to see if there are any problems that are easy to troubleshoot.

As you can see, direct access is faster, but without point syntax security. Therefore, it is appropriate to use the compromise scheme, that is, when the instance variable is written by point syntax, and when the instance variable is read, it is accessed directly. The compromise is more secure, because we may apply some rules when we save, to ensure that problems such as overwriting and copying do not go wrong, and that when you read it, you just have to get the object, and you won't be able to manipulate it (it would be dangerous to change it directly after reading it).

In summary, it is recommended to read the direct access to the time of storage with the dot syntax. Access logic is complex and can be selected as needed.

3, external access as far as possible with the DOT syntax, internal calls as far as possible direct access

First, this does not conflict with the previous point, but it only provides recommendations for use from different dimensions.

External access, do not want the internal implementation of external analysis to determine whether it can be accessed directly, so the uniform use of point syntax is reasonable (of course, if you only set properties, it will not expose the _property variable). Internal invocation, the default user will understand their own logic, so it is fully able to grasp the correct direct access, and this is more efficient, so it is recommended to direct internal access.

Understanding and validation of "IOS" about attributes