Objective c - import .m and .h file - what does it do

Question

In objective c, what actually happened when you say #import "MyClass.h"? (Is the compiler copying something for you?)

1. In MyClass.m file, if I #import "UsefulClass.h", this means that UsefulClass becomes available under this file and I can create object and send message to an instance of it.

2. In myClass.m file, I have to #import "MyClass.h", this sounds like linking my implementation file to its header (called base file?), which feels quite different from what the first one does. So does #import do two different kind of things based on circumstances? Or does it actually fall into one category from another perspective.

3. The method defined in .m file but not in .h file is considered private. From another class, can I invoke the private method somehow? (like if I #import .m instead of .h? so the class will know about what the implementation file defines.)

4. What is the difference between objective-c #import and c #include ?

5. Also @interface MyClass : NSObject is used in .h file and @interface MyClass() is used in the .m file. So is it just a syntax format(like the bracket) when you want to have private properties? or is there any logic behind this?

Answer 1

.h (header file) is the interface of your class and contains 'general description' of your class. When you see the interface, you can say what your class actually do. Sometimes interface can contain a little information or being empty - that means your class can contain private methods and you can't access them through class' interface.

.m (message file in objC, or .c in C, or .cpp in C++, or .mm in objC++) is the implementation of your class.

1 -> When preprocessor see the #import directive, it replaces the line #import "UsefulClass.h" with the text of the file 'UsefulClass.h', so your class MyClass is now "familiar" with class UsefulClass and can use its methods or variables.

2 -> Remember, that class is always consists of interface and implementation (.h + .m). That's why you should make import of your header in .m file. So, the #import does the same thing in first situation and in the second.

3 -> Yes, you can access to private methods. First way: you can inherit from class and all methods (private and public) of it (parent class) are made available in your child class. Second way: yes, you can import .m file. BUT! All these things are not recommended. By agreement you should never access to private methods. When developer makes private methods, he must have a good reason for it. In all, objC hasn't private methods. ObjC extension is the imitation of private method, so objC developer should be careful.

4 -> It's recommended to use #include in C, and #import (or @import in modern version of language) in objC. From the book 'Learn Objective-C on the Mac for OS X and iOS' by Scott Knaster, Waqar Malik, Mark Dalrymple:

#import guarantees that a header file will be included only once, no matter how many times the #import directive is actually seen for that file. Note: In C, programmers typically use a scheme based on the #ifdef directive to avoid the situation where one file includes a second file, which then, recursively, includes the first. In Objective-C, programmers use #import to accomplish the same thing.

5 -> @interface MyClass() is objC category with empty name called extension (it's only objC concept), look at the documentation to understand it. But remember, that it's not actually private thing, it's only imitation.

Answer 2

#include textually copies the contents of the named file into the place where the directive appears. The .h file for a class contains the interface declaration for the class, so you're copying the class's declaration. In both cases (from the class's .m or another file), you are just copying the declaration.

As for #import, it is exactly like #include, except it keeps track of what files it has alread included so you don't end up with the same class declared a bunch of times.

Answer 3

Is the compiler copying something for you? [when you say #import "myClass.h"]?

No, it does not. An #import preprocessor directive is nearly identical to the #include directive, with the exception that it does not need an inclusion guard - a construct borrowed from C, which does not look intuitive.

1. The easiest way to visualize what happens when you #import a .h header into a .m file is to imagine that the content of that header is placed in its entirety on the line replacing the #import. Essentially, that is what the preprocessor does.
2. The same thing happens as in #1 - it does not matter to the preprocessor if the header is related to the .m file or not.
3. A more common way to define private methods and private instance variables is by declaring them in class extensions (see item #5). This keeps all your methods declared, which is a good thing. There are ways to invoke a private method in Objective-C - you could do it through reflection, or you could fake it by defining a signature on a different class, and then invoking it on the class of your choice. The compiler would warn, but it shall obey.
4. I mentioned above that there is no need to use inclusion guards with #import.
5. The interface with empty parentheses is a class extension. It is like a category, but it lets you add instance variables to your class.