Proper way to use Objective C

Answer 1

First, you need to understand that you're making a classic mistake: that the language you already know defines the terms used in all languages - as if a particular language has established a canonical nomenclature.

Java was begun in 1990 internally at Sun. Objective-C had already been released in 1986. So, if anything, Java's interface terminology is at odds with Objective-C, not the other way. However, interface has a lot longer history as a term than either of these languages.

The idea behind the @interface in Objective-C is outlined in the Objective-C 2.0 Programming Language Reference:

interface Part of an Objective-C class specification that declares its public interface, which include its superclass name, instances variables, and public-method prototypes.

instance methods are class methods are public if they are declared in the interface. if they are declared in the @implementation they are private.

The implementation goes into the @implementation. Perhaps what is confusing you is that Java doesn't have the notion of a class declaration section like in Objective-C. The class declaration declares the class interface in a generic way, without specifics of the implementation. The @implementation has the actual implementation, which is the details of how the class @interface is implemented.

It's not wrong that objective-c is different than Java, it's just different.

But you're right, protocols are the closest analog to java interfaces in objective-c you're going to find. It isn't a superclass for anything, and doesn't have any associated implementation. You provide protocols much as you would interfaces in Java.

However, notice that protocols are not as common as classes in Objective-C. That should help guide your thinking.

Answer 2

No-one has yet explained why instance variables appear in the @interface of an Objective-C class. Objects are implemented as C structures which contain the instance variables. When you create a new subclass, a new type of structure is defined with all the superclass's ivars followed by the new class's ivars. The superclass structure must contain the ivars of its superclass, and then it's "turtles all the way down" to a structure which represents the ivars of the base class.

In the case of NSObject (and indeed Object), the base class structure only contains one ivar - a pointer called isa to the Class structure representing this object's class. So if I wanted to subclass it like this:

@interface GLObject : NSObject {
  int x;
}
@end

I need to know how to make a structure which looks like:

{
  Class isa;
  int x;
}

therefore the ivar layout of the parent class (and by induction any class) needs to be part of the class's public contract, i.e. part of its @interface. It may not be pretty, but there it is.

Answer 3

I've also realized there is nothing really forcing my public facing interfaces to contain instance variables...

@interface Foo : NSObject
// some methods but no ivars
+ (Foo*) fooWithBlahBlah
@end

And the implementation file...

@implementation Foo

+ (Foo*) fooWithBlahBlah {
    return [[SomeDerivedFoo alloc] init];
}

@end

Where SomeDerivedFoo is declared internally not visible to clients...

@interface SomeDerivedFoo : Foo
{
    // instance vars
}
// overrides of methods

This would allow the component to expose an interface free of ivar dependencies. In fact this is the model that I see in so called "Class Clusters". This "feels" alot better to me.

My big problem with ivars in the public interface is all about dependency control. If my ivars are nothing but other Objective-C classes then yes I can get away with forward declarations but in the case of embedded C structs or other non class types I have to see the definition of those types and so my clients are now dependent on them.

Changing an instance variable should not cause clients of my interface to recompile. A relink is fine but not a recompile. In the case of a shared framework not even a relink should be necessary. This has nothing to do with any particular language. It has to do with isolation from details. That's a pretty universal goal in my mind.

This is what led to my original question about protocols vs interfaces. It seems that for a library or framework the more "correct" thing to do is to provide a set of protocols along with some sort of "Provider" or "Factory" classes to vend implementations of those protocols.

Answer 4

An alternative if you're not able to support the 64-bit runtime and exclusively synthesise ivars, is to make an id ivar in your class. If you need to return to your class after shipping and add more instance variables, you can use this id as a container for them.

This allows you to write less complex code, while giving you some leeway to change things behind your client's backs without forcing a recompile.

By typing the ivar as id you're not promising anything to client code (an it should be made @private anyway).

I would imagine having all your public classes act as proxies to private implementations would get a little unmanageable. Keep in mind, if you do, you can use runtime forwarding to reduce the amount of code you have to write in the public class. See -[NSObject forwardingTargetForSelector:]. It's documented in the 10.5 Foundation Release Notes