posted by Jared White on Thu 24th Apr 2003 17:49 UTC

"Cocoa 101, Part 1, Page 4"

Now you may be wondering something, and that is: where are all these "standard" Cocoa methods coming from? How is it that your custom objects can use them automatically? The answer is: inheritance, technically known as subclassing. Inheritance is one of the most important aspects of the object-oriented paradigm. The idea is that you start off with a single object class, called the base class or root class, and then every object ever created is a "subclass" of either that class, or any other class that is a subclass of that class. Many classes are subclasses of other classes which are in turn subclasses of another classes which are in turn subclasses, ad nauseam, going all the way back up to the base class.

In Cocoa, the base class is called NSObject. Every object created by Apple, you, or third-parties are going to be subclasses (either directly or indirectly) of NSObject. Again, going back to the above example. MyKindOfObject is a direct subclass of NSObject. You can also say that NSObject is the superclass of MyKindOfObject. The alloc class method and the init instance method are actually defined in NSObject, not your own class. However, you can change this behavior if you wish, because you have the power to override any method inherited from the superclass in your own class. In other words, you could write your own init method to ask another object for important information before completing the initialization process. In that case, your init method would be called instead of the superclass' init method when another object sends your object an init message. But here we come to a dilemma. NSObject's init method contains all kind of special code to deal with memory management and other low-level stuff. If you override it with your own method, that code won't get run. What do you do? Thankfully, there's an easy solution. Objective-C provides two special keywords: self and super. self is a variable that points to the current object itself. super is a keyword that finds the superclass of the object and then points to it. So, if you wanted to write your own init method, you could do this:

- (id)init
{
    self = [super init];
    // custom code goes here
    return self;
}

Here, you're getting the initialized object returned by the superclass' init method and assigning it to self. self must be returned at the end of the method, or your program will crash. But before you return self, you can do anything you like, including creating other objects and setting up instance variables. Which brings me to my final point. Objects are made up of not only methods, but instance variables. Instance variables are variables you can define for a class that you can use to store data internally in the object. For example, a Person object could have an instance variable called fullName, and another one called hairColor. These instance variables could be standard C data types, custom data types, or other objects, just like regular variables. Bear in mind that, by default, instance variables are only available to the object that defines them, and this behavior should very rarely be altered. However, objects commonly allow their instance variables to be changed or retrieved though the use of accessor methods, which I'll explain in Part 2 of this article. Also, an important thing to remember is that every object instance has its own collection of instance variables. So one Person object's fullName variable could contain a "Joe Brown" string and another Person object's fullName could contain a "Mary Smith" string. This type of functionality, along with object methods, is what in object-oriented parlance is called "encapsulation". That is, the implementation of an object (its methods and instance variables) is hidden behind its interface (the messages you can send to it). This allows for modularity, code reuse, and a whole bunch of other cool things. You'll love it.

That's it for Part 1, and it was quite a workout. You learned how Cocoa and Objective-C fit together, what an object is and what a class is, how to send objects messages, what methods and instance variables are, how subclassing works, and more. Next time, in Part 2, you'll learn how to program an object's interface and implementation (a very simple operation), as well as how to create methods that support one or more arguments (input variables), and then we'll start delving into the Cocoa framework itself. Until then, I just want to reinforce the idea that Cocoa programming is really fun. It's easier that it looks, and you can build amazingly-sophisticated programs with comparatively little effort. While some concepts can be difficult to master, nothing is so complex that it can't be easily explained. While waiting for Part 2, I suggest checking out the following Web sites:

Apple's Cocoa Documentation
http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html

Cocoa Dev Central
http://www.cocoadevcentral.com

CocoaDev (a simply wonderful user-contributed WikiWikiWeb site)
http://www.cocoadev.com

Mike Beam's Programming With Cocoa column at MacDevCenter.com
http://www.macdevcenter.com/pub/ct/37

About the Author:
Jared White is President and Art Director of Web site and graphics design company GaelDesign. He is also Editor-in-Chief of The Idea Basket, an e-zine featuring provocative news commentary, articles, editorials, and reviews related to software and interface design, the Internet, multimedia, and technology. Jared became a PC-to-Mac switcher in 2001 and has been having a blast with Cocoa ever since. He can be reached via e-mail at jwhite@gaeldesign.com.

Table of contents
  1. "Cocoa 101, Part 1, Page 1"
  2. "Cocoa 101, Part 1, Page 2"
  3. "Cocoa 101, Part 1, Page 3"
  4. "Cocoa 101, Part 1, Page 4"
e p (0)    56 Comment(s)

Technology White Papers

See More