Why are Objective-C instance variables declared in an interface?

Question

I just fall into Objective-C (Java is my main OO language).

Defining object instance variables in an interface instead of a class seems strange. I'm used to the interface, which is the public definition of the API, and nothing but method signatures (not counting the constants here).

Is there any reason that the state is defined in the interface (even if it is private) and the behavior is defined in the class. It just seems strange that since objects are states + behavior, the definition will be divided into two separate places.

Is this one of the design advantages? Pain in the back release that you just have to deal with in Objective-C? Not a problem, just another? Are there any suggestions as to why this was done?

Or can you put the state of an object in a class, and I just haven't hit that part in my book yet?

Answer 1

UPDATE

The answer below was written before the language function of declaring instance variables in the implementation was implemented. Submitting a question is now no longer valid. As FireLizzard says @interface is no need to @interface anything to @interface .

---

This is a hangover because Objective-C came about as a rather thin layer built on top of C. The C path is to define the interface to the module (not to be confused with the Java interface ) in the header of the file and literally include it in each compilation unit. This is similar to automatically copying pasting declarations at the beginning of each compiled file. If this seems primitive, it is because it is there, but C is a 40-year-old language.

You must define instance variables - even private ones - in the interface, because Objective-C objects are implemented as C-structures, which themselves are simply memory blocks and named offsets inside this block. The structure representing the object of each class must contain space for instance variables of the superclass, so subclasses must know at least the size of the C structure representing the superclass, as well as the offset of the public and protected instance variables. This, unfortunately, means that all instance variables, even private ones, must be represented as part of the external interface. * C ++ another version of OO C suffers from the same problem for the same reasons.

It's a bit of a pain when you have to write down all the method signatures twice, but you get used to it.

* With the 64-bit version of the time, you no longer need to declare ivars for synthesized accessors in @interface , but since all methods are publicly available, it still means exposing the internal state to the outside world, especially since it facilitates the <href = "http: problem: //en.wikipedia.org/wiki/Fragile_base_class "rel =" nofollow noreferrer "> of a fragile base class.

Answer 2

Objective-C does not reference an instance at all

Brad Cox, who developed Objective-C, decided that the equivalent of C declarations and definitions should be explicit, so that each class has an @interface section telling it is externally externally and an @implementation telling how it is implemented.

Java appeared later and changed the object model, so that there is only one definition of the object that combines @interface and @implementation. The compiler (and runtime introspection) actually creates an interface from the code.

The equivalent of an interface in Java is the protocol in Objective C.

You just get used to it.