Introduce as few header files as possible in Class header files & lt; Objective-C & gt;, swift introduces header files

Introduce as few header files as possible in Class header files <valid Objective-C>. swift introduces header files.

Like C and C ++, Objective-C uses header files and implementation files to separate code. The standard method for compiling "class" in Objective-C language is to create two files by using the class name as the file name, and use the suffix of the header file. h To implement the file suffix. m. After a class is created, its code looks as follows:

// EOCPerson.h#import <Foundation/Foundation.h>@interface EOCPerson : NSObject@property (nonatomic, copy) NSString *firstName;@property (nonatomic, copy) NSString *lastName;@end

// EOCPerson.m#import "EOCPerson.h"@implementation EOCPerson// Implementation of methods@end

Almost all classes written in the Objective-C language need to be introduced to Foundation. h. If this file is not introduced in the class itself, it is necessary to introduce the "basic header file" (base header file) corresponding to the framework to which the super class belongs ). For example, when creating an iOS application, the UIViewController class is generally inherited. The header files of these sub-classes need to introduce UIKit. h. It seems that the EOCPerson class is fine. Its header file introduces the entire Foundation framework, but this is not a problem. If this class inherits from a class in the Foundation framework, then the EOCPerson class user (consumer)
Many contents in the base class may be used. The same applies to classes inherited from UIViewController. Users may use most of the content in UIKit.
After a while, you may have created a new class named EOCEmployer. Then, you may feel that each EOCPerson instance should have an EOCEmployer. Therefore, add an attribute directly for it:

// EOCPerson.h#import <Foundation/Foundation.h>@interface EOCPerson : NSObject@property (nonatomic, copy) NSString *firstName;@property (nonatomic, copy) NSString *lastName;@property (nonatomic, strong) EOCEmployer *employer;@end

However, when compiling the EOCPerson. h file, the EOCEmployer class is invisible. It is inconvenient to force developers to introduce EOCEmployer. h when introducing EOCPerson. h.
You can add the following line to EOCPerson. h:
#import "EOCEmployer.h"

This method is feasible, but not elegant enough. You do not need to know when compiling a file that uses the EOCPerson class.
For all the details of the EOCEmployer class, you only need to know that there is a class named EOCEmployer. Fortunately, there is a way
The compiler can tell this situation:
@class EOCEmployer;

This is called the forward Declaration class. The header file of EOCPerson is changed to the following:

// EOCPerson.h#import <Foundation/Foundation.h>@class EOCEmployer;@interface EOCPerson : NSObject@property (nonatomic, copy) NSString *firstName;@property (nonatomic, copy) NSString *lastName;@property (nonatomic, strong) EOCEmployer *employer;@end  

The implementation file of the EOCPerson class must introduce the header file of the EOCEmployer class, because to use the latter
All its interface details must be known. Therefore, the implementation file is:

// EOCPerson.m#import "EOCPerson.h"#import "EOCEmployer.h"@implementation EOCPerson// Implementation of methods@end  

Try to delay the time for introducing header files, and only introduce the files if necessary. This can reduce the number of header files to be introduced by class users. Assume that EOCEmployer. h is introduced to EOCPerson. h In this example, all content of EOCEmployer. h is introduced as long as EOCPerson. h is introduced. If this process continues, You need to introduce
This will certainly increase the Compilation Time.
The Forward Declaration solves the issue of mutual reference between two classes. If you want to add or delete an employee to the EOCEmployer class, the following definitions will be added to the header file:

- (void)addEmployee:(EOCPerson*)person;
- (void)removeEmployee:(EOCPerson*)person;


At this point, to compile EOCEmployer, the compiler must know the EOCPerson class, and to compile EOCPerson, it must know EOCEmployer. If the header file of the other party is introduced to the header file, it will lead to "chicken-and-egg situation ). When parsing one of the header files, the compiler will find that it introduces
And the header file is back to reference the first header file. Using the # import instead of # include command won't lead to an endless loop, but it means that one of the two classes cannot be correctly compiled. If you do not believe it, you can try it on your own.
But sometimes other header files must be introduced into the header file. If the class you write inherits from a super class, you must introduce the header file that defines the super class. Similarly, to declare that the class you write complies with a protocol, the protocol must have a complete definition and cannot use a Forward Declaration. The Forward Declaration can only tell the compiler that there is a protocol.
The compiler needs to know the methods defined in the Protocol.
For example, to inherit a rectangular class from the graphic class and follow the drawing protocol:

// EOCRectangle.h#import "EOCShape.h"#import "EOCDrawable.h"@interface EOCRectangle : EOCShape<EOCDrawable>@property (nonatomic, assign) float width;@property (nonatomic, assign) float height;@end

Article 2#importIt is inevitable. In view of this, it is best to put the Protocol in a separate header file. If you put the EOCDrawable protocol in a large header file, as long as you introduce this protocol, it will certainly introduce that header file.
In this way, as mentioned above, the issue of mutual dependency will occur and compilation will be increased.
Time.
However, some protocols, such as the "delegate protocol", do not have to write a separate
Header file. In that case, the Protocol is meaningful only when defined together with the class that accepts the Protocol delegate. It is best
You can declare this class in the implementation file to implement the delegate protocol, and place this implementation code in the "class-continuation
Class-continuation category. In this case, you only need to include
The header file of the delegate protocol does not need to be placed in the public header file. Before introducing other header files to the header file, you must first ask yourself if this is necessary. If you can replace the introduction with the Forward Declaration, do not introduce it. If header files must be introduced because attributes, instance variables, or protocols are to be implemented, move them to "class-continuation Classification" whenever possible. This not only reduces the Compilation Time, but also reduces the degree of dependency between each other. If the dependency is too complex, maintenance will be troublesome. If you only want to open a part of the code as a public API, too complicated dependencies will also cause problems.
Key points:

• Do not introduce header files unless necessary. In general, forward sound should be used in the header file of a class.
  Class, and introduce the Class header files in the implementation file. This can reduce the number of classes as much as possible.
  Coupling ).
• Sometimes forward declaration cannot be used, for example, to declare that a class complies with an agreement. In this case, try to move the statement "this class complies with a certain protocol" to "class-continuation classification. If not, put the Protocol in a separate header file and introduce it.