CODEWITHSUNDEEP
objective-c
Ale
Ale

Reputation: 1187

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

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!

Upvotes: 2

Views: 320

Answers (5)

echristopherson
echristopherson

Reputation: 7074

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.

Upvotes: 0

Graham Perks
Graham Perks

Reputation: 23390

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++?

Upvotes: 0

Tommy
Tommy

Reputation: 100622

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.

Upvotes: 1

Patrick Borkowicz
Patrick Borkowicz

Reputation: 1216

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.

Upvotes: 5

Michael Dautermann
Michael Dautermann

Reputation: 89509

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).

Upvotes: 0

Related Questions