Many of the veterans who have developed iOS for several years may not be very clear about the use and differences of the various structures in the. h file and the. m file. Recently studied carefully, wrote an article to write down.
Generally, when writing a class, it is often this format (as an UIViewController
example):
. h file:
@interface ClassName{ NSString* _value1;}@property(nonatomic,assign)NSString* value1;-(void)func1;
. m File:
@interface ClassName(){}@end@synthesize value1;@implementation ClassName-(void)func1{}@end
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
This is basically the format. Many people, including me, use such templates directly when creating and using class. There are some interesting little things in this template that are worth exploring, such as:
1. Why are there 1 of. h files and. m files @interface
? What are they used for?
2.. h, why does the value1 define 2 times?
3. @synthesize
What's the use?
There are a few other questions that will be addressed today first.
Why are there 1 @interface in. h files and. m files? What's the use of them respectively?
The. h inside @interface
, needless to say, is a typical header file that is intended for other class calls. Both its @property
and functions can be "seen" by the other class.
The. m inside @interface
, called the class Extension in OC, is a supplement to the. h file. @interface
But in the. m file @interface
, the external is not open, only visible in the. m file.
Therefore, we put the methods and variables of opening up into the. h file, and the variables that do not want to open up to the. m file (the. m file method may not be declared, directly used).
Some students see class Extension, may think of OC @protocol
. Yes, they are all extensions to a class. But the difference is also obvious:
Class extension can only be used when the source code can be obtained, and in the case of the source is @protocol
not available to use.
Therefore, it is commonly @protocol
used as an extension to some system classes, such as NSString, UIView, and so on.
. h, why do value1 define 2 times?
Of course, @interface{}
the definition of the present can be omitted, but the principle is still to understand.
The Strictly @interface{}
defined variable, called instance variable, is the real global variable inside the class. However, this instance variable is not open to the public, so we also need a public thing to call, that is @property
@property is external, it is actually to tell you, I this class, there is a variable Set/get method. For example, @property NSString* string;
in this class there is a getstring/setstring for you to call.
Therefore 2 declarations are required. Of course now the LLDB is upgraded, and as long as you declare @property
it, it can automatically create the corresponding global variables.
What's the use of @synthesize?
@property
After a variable, in a @implementation
second @synthesize
, I believe it is a habit of many people. But why do we have this @synthesize method?
@property
is to declare the Get/set method of class, and then we need to write the Get/set method in the. m file. This can be troublesome, 1 variables corresponding to 2 methods, if there is 10 variables in a class, it is not to write 20 methods? I'm bored with the chatter.
@synthesize helped us solve the problem. @synthesize
the Get/set method is automatically generated in the. m file. So we just add a @implementation
line to the following: We @synthesize
can automatically generate the Get/set method, which saves a lot of trouble. For example @synthesize value1 = _value1;
, the instance variable _value1 is used as a getValue1 and setValue1 method.
The Get/set method is sometimes more complex because it is related to the properties of a variable, which is related to @property(nonatomic, assign/retain(strong/weak))
memory. However @synthesize do these things for us, do not worry about these things again!
More conveniently, starting from Xcode4.4, the compiler will automatically add a corresponding one for each bar @property
@synthesize
, so we'll just write a @property!
PS: None of this seems like a thing in Swift. It is a sin to say that there is no contact with Swift.
Objective-c. h files,. m files @interface, @synthesize and others