What's the point of the Interfaces in Objective C?

Question

I've been programming Objective C for almost a year, and I've never had the chance to use the Interface (.h) for another purpose than declare almost the same class structure that you can find in the Implementation (.m).

Since I come from other languages with no such thing as the Objective C's Interface, I wonder if there's some or several uses that I'm missing or if this is just a convention that this particular language has maybe inherited from its predecessors.

Thanks!

It's for including in other files so that other files don't need to process the implementation. — Daniel, Jun 01 '12 at 19:31
Objective-C has gotten pretty magically lately, but behind the scenes, a Class is basically a struct declaration, the interface tells the compiler how big the data structure is. — Grady Player, Jun 01 '12 at 19:46

score 5 · Answer 1 · answered Jun 01 '12 at 19:33

5

Your interface is the public API of the class. Anything NOT declared in the interface can't be accessed from outside the class. If you think more in terms of C++ or Java, everything in the .m file (that is NOT declared in the @interface in .h) is private. That's why you won't see they keywords @private, @public or @protected too often in Objective-C.

Whatever you put in your interface is what you intend to user of your class to work with and nothing more. This follows the principle of least privilege.

You can also think of @interface as the documentation for your class.

answered Jun 01 '12 at 19:33

Patrick Borkowicz

1,206
10
19

True, but remember that there is no such thing as anything being truly 'private' in objective-c. It isn't difficult to find your private APIs and exploit them. – Richard J. Ross III Jun 01 '12 at 19:36
Technically things not declared in the interface can be accessed — e.g. you can send any selector to any object irrespective of what its @interface declares — you'll just be aware that you're doing irresponsible hacky stuff. – Tommy Jun 01 '12 at 19:36
Quite right, Objective-C is a little more based on the idea that the user knows what their doing and therefore should have access and if you use something like respondstoSelector or introspection then you should know what your getting into. – Patrick Borkowicz Jun 02 '12 at 03:37

score 1 · Answer 2 · answered Jun 01 '12 at 19:42

I've never had the chance to use the Interface (.h) for another purpose than declare almost the same class structure that you can find in the Implementation (.m).

The interface is the publicly declared interface to the class. The implementation is how it honours that interface. A trivial example then:

@interface Accumulator: NSObject

- (void)addAmount:(NSUInteger)amount;

@property (nonatomic, assign, readonly) NSUInteger currentTotal;

@end

And:

@implementation Accumulator
{
    NSUInteger currentTotal; // an instance variable; we don't want to publish
                             // these because they're nothing to do with the
                             // interface we implement. Object orientation means 
                             // not thinking about implementations beyond
                             // your own.
}

@synthesize currentTotal;

- (void)addAmount:(NSUInteger)amount
{
     currentTotal += amount;
}

@end

So, as general guidelines, amongst the things you don't put into your @interface are:

instance variables;
methods that aren't intended for external use;
references to other classes that you rely on but which people that rely on you don't need to know about.

Here Tommy focused very well in the *use*. I would like to add some words about the *cause* of this class-structure: It seems that it would be the _oldness_ of Objective C. At the time it was created (80's), memory was just too expensive to let the linker browse to all the functions of a class. A _lighter_ to do it way was to have a header file with the declaration of that class, and have the linker working from there. (From Wikipedia:) Some newer languages use instead a naming scheme that allows the compiler to locate the source files associated with interfaces and class implementations. — Ale, Jun 02 '12 at 06:04

score 0 · Answer 3 · answered Jun 01 '12 at 19:30

The interface file is analogous to the header file used in C & C++, only in Objective C, you can also declare such nice things as properties and protocols (super useful for things like delegates that need to confirm to how your object's interface is expecting to pass messages along).

Your object's interface file can be included in other object's implementation (.m) files so that way those other object's implementation can access methods & properties of the object you've just instantiated (created).

score 0 · Accepted Answer · edited May 23 '17 at 12:11

It's inherited from C, where you have headers defining interface, and source files containing the implementation. It does mean some double-entry.

Java, for example, does away with this two-files approach and has a single file containing everything. It doesn't have C's compile & link phases which are part of the reason for the headers.

One aspect to the header approach is, with proprietary code, you can give someone your headers along with compiled binary files, and they can link to & call your APIs just fine. This is what Microsoft does with the Win32 API, or what Apple does with their SDK and OS.

Also see Why have header files and .cpp files in C++?

Great link, particularly this answer:http://stackoverflow.com/a/333964/862724 seems to have the key. — Ale, Jun 02 '12 at 05:44

score 0 · Answer 5 · answered Jun 01 '12 at 20:35

To expand on what's already been said: C-based language compilers require a certain amount of knowledge about the words in a .c/.cpp/.m file before they ever get around to linking in external libraries or object files. That information tells the compiler things like return types and the number and types of arguments of function and methods, and the instance variables and methods in classes.

If you were to actually include whole .c/.cpp/.m files inside the files that use their functionality, you would end up with a problem where the linker has duplicate code that it doesn't know what to do with; thus a header file just lists what they actually need to know about the interface, but not the implementation.

C and Objective-C actually allow you to omit various sorts of interface information, but they consequently make (often incorrect) assumptions if they see mentions of functions or methods whose headers they haven't read. For instance, an unknown function name will be correctly indentified as such, but the compiler will assume that it returns an int; my memory's a bit hazy on how arguments are handled, but it won't likely complain if you pass arguments that are incompatible with the ones in the implemented function that eventually gets linked in. Thus the compiler is unable to do a lot of the checks that static languages like C are good at.

What's the point of the Interfaces in Objective C?

5 Answers5