NSApplication and delegate

Last night, I finally restarted my Cocoa learning effort, by looking at how I could write an application without using Interface Builder. IB is so vastly used that there isn't as much details available on the web on how to go about with it, nevertheless, there is enough to get started. And in fact, it is relatively easy, at first.

A Cocoa application, in its simplest expression, is composed of a single NSApplication object and one (or more) NSWindow object(s). Overall, it doesn't take much boiler code to get something going, which is good:

int main(int argc, char *argv[])
{
NSWindow *lWindow;
// create an auto-release pool
NSAutoreleasePool *lPool = [[NSAutoreleasePool alloc] init];

// initializes the display environment and connects to the window server
// and display server
[NSApplication sharedApplication];

// create a window
lWindow = [[NSWindow alloc] initWithContentRect:NSMakeRect(10,10,320,240)
                             styleMask:kStyle
                               backing:NSBackingStoreBuffered
                                 defer:NO];
// set the window's title
[lWindow setTitle:@"Hello world!"];
// show the window and move it foreground
[lWindow makeKeyAndOrderFront:nil];

// start the application run loop
[NSApp run];

// release the window
[lWindow release];

// release the pool
[lPool release];
}

The Application object gets a bunch of notification from the system during its life-time. If I wanted to perform some actions in some of them, there is two ways of doing it: I could subclass NSApplication and implement the corresponding methods, which is the usual way of doing it in 99% of the toolkits out there ... or, I could follow the Cocoa way and use a delegate instead. Since the later is what Apple encourage developers to do, the NSApplication class is built to support the addition of a delegate by sending it a setDelegate message.

Now, as expected, this message take as single argument: the object to be the delegate. So far so good. However, instead of defining the argument with a specific class, for example something like said NSApplicationDelegate, it is defined as an id (meaning any kind of object). Since I'm still more of a C++ kind of guy than an Objective-C dude, I found myself a little puzzled by this but still decide to move forward by searching in NSApplication.h (since I didn't see anything in the class documentation) for the delegate class I am expecting to have to subclass, or some sort of protocol definition.

In the header file, I was nicely surprised to see that NSApplicationDelegate does exists, but in a way I was not expecting, at all: @interface NSObject(NSApplicationDelegate). Yep, that's right. A category ... meaning that any object with NSObject for root parent, can be the application delegate ... Since 99% of all Cocoa's classes have NSObject as root, any objects can be the delegate .... including widgets! If this isn't yucky, I don't know what is! Why on earth didn't they use a protocol!??