@class vs. #import

for extra info about file dependencies & #import & @class check this out:

[

[To see links please register here]

][1]
itis good article

summary of the article

> #imports in header files:
- #import the superclass you’re inheriting, and the protocols you’re implementing.
- Forward-declare everything else (unless it comes from a framework
with a master header).
- Try to eliminate all other #imports.
- Declare protocols in their own headers to reduce dependencies.
- Too many forward declarations? You have a Large Class.

> #imports in implementation files:
- Eliminate cruft #imports that aren’t used.
- If a method delegates to another object and returns what it gets
back, try to forward-declare that object instead of #importing it.
- If including a module forces you to include level after level of
successive dependencies, you may have a set of classes that wants to
become a library. Build it as a separate library with a master
header, so everything can be brought in as a single prebuilt chunk.
- Too many #imports? You have a Large Class.

[1]:

[To see links please register here]

"#imports Gone Wild! How to Tame File Dependencies"

Another advantage: Quick compilation

If you include a header file, any change in it causes the current file also to compile but this is not the case if the class name is included as `@class name`. Of course you will need to include the header in source file

If you see this warning:

> warning: receiver 'MyCoolClass' is a forward class and corresponding @interface may not exist

you need to `#import` the file, but you can do that in your implementation file (.m), and use the `@class` declaration in your header file.

`@class` does not (usually) remove the need to `#import` files, it just moves the requirement down closer to where the information is useful.

**For Example**

If you say `@class MyCoolClass`, the compiler knows that it may see something like:

MyCoolClass *myObject;

It doesn't have to worry about anything other than `MyCoolClass` is a valid class, and it should reserve room for a pointer to it (really, just a pointer). Thus, in your header, `@class` suffices 90% of the time.

However, if you ever need to create or access `myObject`'s members, you'll need to let the compiler know what those methods are. At this point (presumably in your implementation file), you'll need to `#import "MyCoolClass.h"`, to tell the compiler additional information beyond just "this is a class".

Three simple rules:

- Only `#import` the super class, and adopted protocols, in header files (`.h` files).
- `#import` all classes, and protocols, you send messages to in implementation (`.m` files).
- Forward declarations for everything else.

If you do forward declaration in the implementation files, then you probably do something wrong.

Think of @class as telling the compiler "trust me, this exists".

Think of #import as copy-paste.

You want to minimize the number of imports you have for a number of reasons. Without any research, the first thing that comes to mind is it reduces compile time.

Notice that when you inherit from a class, you can't simply use a forward declaration. You need to import the file, so that the class you're declaring knows how it's defined.

This is an example scenario, where we need @class.

Consider if you wish to create a protocol within header file, which has a parameter with data type of the same class, then you can use @class. Please do remember that you can also declare protocols separately, this is just an example.

// DroneSearchField.h

#import <UIKit/UIKit.h>
@class DroneSearchField;
@protocol DroneSearchFieldDelegate<UITextFieldDelegate>
@optional
- (void)DroneTextFieldButtonClicked:(DroneSearchField *)textField;
@end
@interface DroneSearchField : UITextField
@end

Look at the Objective-C Programming Language documentation on [ADC][1]

Under the section on Defining a Class | Class Interface it describes why this is done:

> The @class directive minimizes the amount of code seen by the compiler and linker, and is therefore the simplest way to give a forward declaration of a class name. Being simple, it avoids potential problems that may come with importing files that import still other files. For example, if one class declares a statically typed instance variable of another class, and their two interface files import each other, neither class may compile correctly.


[1]: