Objective-C Part 1: the Basics of Objects and Classes

So, I have been asked to write a post explaining Objective-C. Objective-C is not an easy language to learn; I learned it by reading the several hundred paged language documentation on the Apple iPhone developer website. Yes, I did it in an afternoon, but it was not an easy afternoon. Objective-C is difficult because of what it is: a layer built on top of C; it cannot use syntax that would conflict with the existing C syntax. Objective-C is also, apparently, a dynamic language. The design of Objective-C is very different from, say, ActionScript or Java. I’m not sure how to really go about explaining this language, as I do not really have any good ideas for a tutorial project. I guess I can try to do this as a series of posts, and so, I will start with the basic concept of objects in this language.

Objects in ObjC are sent messages. The basic syntax is [recievingObject message];. A message is named partially through its parameters. This is a bit tricky. [recievingObject messageName:(arg1) otherThing:(arg2)]. Confused? I thought so. Maybe understanding how classes are defined would help.

@interface ClassName : Parent
{
    type iVar1;
    ...
}
- (retType)messageName:(type)arg1 otherThing:(type2)arg2;
@end

You see on line 6 a method being defined (implementation is, in fact, separate from definition on ObjC). The true name of this message is messageName:otherThing. This leads to a strange naming practice of making the method name include a name or such for the first argument. Very strange. Also, the name of these variables will be referred to as arg1 and arg2 inside the scope of the method.
The definition of a class is done inside the @interface and @end compiler tags. The names of the messages that a class or an object can receive are done here. Yes, classes can in fact be sent messages, as they are in a way, objects. You may have noticed the - in front of the definition on line 6. That symbol tells the compiler that there is a instance method being defined. To define a class method, instead, you use a + sign.
As I have mentioned, class implementation is separated from class definition; this is reflected in the separation of class definition files and implementation files: for the class ClassName, the definition would go in a file ClassName.h, and the implementation would go in ClassName.m, which would like this:

#import "ClassName.h" //very important that it import its own interface
@implementaton ClassName : SuperClass
- (retType)messageName:(type)arg1 otherThing:(type2)arg2
{
    //do things
    /* here are the variables in this scope automatically:
       arg1, arg2, self (the instance object itself)
       any instance variables
     */
}
@end

Now, let me cover some unfortunate/painful aspects of this language.
First, because it is written in C, you will probably run into that horror known as pointers. I do not understand them well enough to explain them, but I can explain a few things that might allow you to avoid trouble. ObjC objects are understood by C to be of type id. However, for type purposes, and polymorphism, it is more useful to specify the type of an object. For example, you could have a string as id stringObject = (some ObjC string object, such as NSString), but it may be more useful to refer to this as NSString *stringObject = (thing). Whenever specifying the object type of a variable, you must declare it as a pointer, using the * symbol. Yes, this is not really good. Can it get worse? Oh yes.
C does not have a built in garbage collector. Working in C means living dangerously. Objective C uses the root object, NSObject, or some other object type depending on which framework you are using, to do memory management (among other things, as far as I can tell). Now, when constructing an object, first you must get an instance through allocating memory for it. This is done through a class method: [NSObject alloc]. Then, you initialize this: [[NSObject alloc] init]. Of course, initializers with arguments are not called init, but initWithSomeVariable:andAnotherVariable:andAnUtterlyGratuitousVariable.
At some point, you might ask what those brackets are doing everywhere. Why aren’t they using dot-syntax, like any decent object oriented language? Well. C is the problem here. C uses dot-syntax to access members of structs. However, using properties will allow you to make getters and setters that will mimic the dot syntax for getting and setting properties. The basic syntax is:

@interface ClassName : NSObject //in the interface definition file
{
    NSObject *iVar1; //good example of the deal with pointers
}
@property(attributes) NSObject *iVar1;
@end

The attributes of the property define: which accessors to create, how you want the property to be set, and if it should be nonatomic. This is only important if you decide to go with path 2 in the next bit.

@implementation ClassName
/*now, there are two ways of doing this. The hard way is
@dynamic iVar1;
which requires that YOU implement the getter and setter yourself.
*/
//however, the easier way is to have them synthesized
@synthesize iVar1;
@end

If you decide to synthesize, the getters and setters will be created according to the attributes defined in the interface. Now, here are these attributes:

• getter=(name) specifies what you want the getter to be called
• setter=(name) specifies name of setter, only valid if the property is
• readwrite, the default, and causes both a getter and setter to be created, as opposed to
• readonly, which only creates a getter. now, we specify the functionality of the setter with one of
• assign, the default, which means that simple assigning of the variable should be used
• retain, which means that the retain method will be called for the object (what this means is not fully clear to me), and
• copy, meaning that a copy of the object should be assigned. Only NSCopying objects are legal for this
• nonatomic, off by default, changes the behavior of synthesized accessors in a way that affects threading. I do not fully understand this.

Well, that should settle the basics of objects and classes in ObjC. If it does not, we can discuss things in the comments. For the next part, I will attempt to explain such things as inheritance, dynamic method resolution, protocols, categories, extensions, and other subjects that I group together because they seem to fit what I think of as an utter mess of crazynessadvanced aspects of objects and classes in ObjC.

~ by raptros-v76 on August 27, 2008.