1. Introduction
When we look at the code, we often find that some places use @class and some places use #import, what is the difference between them?
This article intends to generalize and summarize the processing methods and rules referred to in these two categories.
2. Analysis
This section explains the differences in how to refer to header files by using some instance code.
1. First we create a single View application project, which adds a Xfperson class that inherits from NSObject.
2. Observe the error cause of the following code:
Declare a Xfperson variable in VIEWCONTROLLER.M.
Although the relevant files for Xfperson are in the project, but to refer to this class in other classes, you must tell the current class the information of this class, in other words, let the current class know the basic information of the class to be referenced.
We can use two kinds of processing, we can use the @class tag directly or use #import to include the header file of the reference class.
Both of these methods provide information about the reference class that is currently available, but the level of detail of the information is not the same.
3. Direct use of @class
First of all to discuss the @class tag, in fact, it provides the least information, it can be said that it just tells the current class of the current Class "You refer to the class is there, that is called the name, what he can do I do not know", sometimes we will @class call
Pre-stated. Based on this we will change the VIEWCONTROLLER.M as follows, introducing Xfperson class information through @class:
We can see that in this way, the current class is relieved to declare a reference class variable.
But when we continue to create the Xfperson object, we find the following error:
The error that Xcode prompts is already
Clearly, Xfperson for the current class is only "forward declaration" pre-declaration, the current class because the information provided by @class only believe that Xfperson does exist, because
There is too little information to know what the method is in this class, which is what he can do. So when we try to invoke some of the methods of Xfperson, we make mistakes.
This is the time for #import to be shot!
4. Using #import to refer to the header file of a class
When you replace @class with #import, the compilation is normal:
5. References to base class header files
Open the XFPerson.h file and you will see Xcode automatically referencing some of the system's header files:
The reason is that our class inherits from NSObject, so we have to introduce the nsobject of this parent class to the subclass's header file #import way.
We can explain this in the following examples:
We created a new class named: Xfanimal, which also inherits from NSObject
Then we change the Xfperson's parent class to Xfanimal:
We see the compiler does not know the xfanimal information, then we use the @class indicator is it feasible?
Still error, the cause of the mistake is also very clear.
We then use #import to introduce the Xfanimal header file:
Everything's fine.
3. Summary
We can see that #import can be used in. h as well as in. m, so how exactly should we judge?
Usually just remember:
1. If the subclass integrates the parent class, the parent class's header file needs to be #import to the child class's header file.
2. If a class is referenced in a. m file, you need to #import the header file of the class into a. m file.
So in the above analysis process found #import and @class compared to the information provided richer, why not directly use #import?
We see in the official Apple documentation:
The @class directive minimizes the amount of code seen by the compiler and linker, and is there fore the simplest-to-g Ive a forward declaration of a class name. Being simple, it avoids potential problems, the come with importing files, the import still other files.
So the final conclusion is:
Can use @class place must use @class, must use #import of time only to use #import
[New Learn] The difference between @class and #import use